UNIT V

MICROSERVICES AND DEVOPS

Defining Microservices:
1) Microservices is an architectural design for building a
distributed application using containers. They get their
name because each function of the application operates
as an independent service. This architecture allows for
each service to scale or update without disrupting other
services in the application.
2) A microservices framework creates a massively scalable
and distributed system, which avoids the bottlenecks of
a central database and improves business capabilities,
such as enabling continuous delivery/deployment
applications and modernizing the technology stack.
What is DevOps
• If you want to build better software faster, DevOps is the
answer. Here’s how this software development methodology
brings everyone to the table to create secure code quickly
• DevOps combines development and operations to increase the
efficiency, speed, and security of software development and
delivery compared to traditional processes.
• A more nimble software development lifecycle results in a
competitive advantage for businesses and their customers.
DevOps (“development” and “operations”) is the combination of
practices and tools designed to increase an organization's ability
to deliver applications and services faster than traditional
software development processes.
Emergence of Microservice Architecture:
SOA provides solutions to most of the issues that monolithic
applications face. But developers still have concerns about
creating a much more scalable and flexible system. It's easy to
construct a monolithic structure.
The emergence of container technology, developers have been
able to provide a simple way to build and manage large-scale
software applications. Instead of building single indivisible units,
the design of microservices focuses on building components
separately and integrating them with language-independent APIs.
Containers provide an infrastructure for applications to run
independently.
Design Patterns of Microservices
1. Aggregator
2. API Gateway
3. Chained or Chain of Responsibility
4. Asynchronous Messaging
5. Database or Shared Data
6. Event Sourcing
7. Branch
8. Command Query Responsibility Segregator
9. Circuit Breaker
10. Decomposition
Microservice architecture has become the de
facto choice for modern application
development
The Mini web service architecture
The architecture of web service interacts among three
roles: service provider, service requester, and service registry.
The interaction involves the three operations: publish,
find, and bind. These operations and roles act upon the web
services artifacts. The web service artifacts are the web service
software module and its description.
Microservice dependency tree:
Challenges with Microservices
Microservice architecture is more complex than the legacy
system. The microservice environment becomes more
complicated because the team has to manage and support many
moving parts.
Bounded Context
Dynamic Scale up and Scale Down
Monitoring
Fault Tolerance
Cyclic dependencies
DevOps Culture
Bounded context:
The bounded context concept originated in Domain-Driven
Design (DDD) circles. It promotes the Object model first
approach to service, defining a data model that service is
responsible for and is bound to.
Dynamic scale up and scale down:
The loads on the different microservices may be at a different
instance of the type. As well as auto-scaling up your microservice
should auto-scale down.
Monitoring:
The traditional way of monitoring will not align well with
microservices because we have multiple services making up the
same functionality previously supported by a single application.
Fault Tolerance:
Fault tolerance is the individual service that does not bring down
the overall system
Cyclic Dependency:
Dependency management across different services, and its
functionality is very important.
DevOps Culture:
Microservices fits perfectly into the DevOps. It provides faster
delivery service, visibility across data, and cost-effective data
SOA vs Microservice
Microservice and API
A microservice contains all the code required for a particular
application function. An API is a communication mechanism
to access that function.
Microservices expose functionality via APIs so other
microservices can use them when required.
1. Microservices :
Microservices Architecture is an architectural style that
structures an application as a collection of small autonomous
services modeled around a business domain. In a Microservice
Architecture, each service is self-contained and implements a
single business capability.
It is a popular way where we build web applications now,
for those reasons we outlined above. To recap, an architecture
makes it easier and faster to build and work on individual parts
of an application, and thus the application as a whole.
2. Application Program Interface (API) :
Application Program Interface (API) is a way through which
you can make sure two or more applications communicate with
each other to process the client request.
Difference between Microservice and API :
Deploying and maintaining Microservices
Microservice applications can run in many ways, each with different
tradeoffs and cost structures. What works for small applications
spanning a few services will likely not suffice for large-scale systems.
Single machine, multiple processes: buy or rent a server and run the
microservices as processes.
Multiple machines, multiple processes: the obvious next step is
adding more servers and distributing the load, offering more
scalability and availability.
Containers: packaging the microservices inside a container makes it
easier to deploy and run along with other services. It’s also the first
step towards Kubernetes.
Orchestrator: orchestrators such as Kubernetes or Nomad are
complete platforms designed to run thousands of containers
simultaneously.
Serverless: serverless allows us to forget about processes, containers,
and servers, and run code directly in the cloud.
Reason for having DevOps
DevOps describes a culture and set of processes that bring
development and operations teams together to complete software
development.
1. Shorter Development Cycles, Faster Innovation
When development and operations teams are in separate silos, it’s
usually difficult to tell if an application is ready for operations.
When development teams simply turn over an application
2. Reduced Deployment Failures, Rollbacks, and Time to Recover
Part of the reason teams experience deployment failures is due to
programming defects. The shorter development cycles with
DevOps promote more frequent code releases.
This, in turn makes it easier to spot code defects. teams can reduce
the number of deployment failures using agile programming
principles that call for collaboration and modular programming.
3. Improved Communication and Collaboration
DevOps improves the software development culture. Combined
teams are happier and more productive.
The culture becomes focused on performance rather than
individual goals.
4. Increased Efficiencies
Increased efficiency helps to speed the development process and
make it less prone to error. There are ways to automate DevOps
tasks.
Continuous integration servers automate the process of testing
code, reducing the amount of manual work required.
5. Reduced Costs and IT Headcount
The DevOps benefits translate to reduced overall costs and IT
headcount requirements. According to Kevin Murphy from Red
Hat, DevOps development teams require 35 percent less IT staff
and 30 percent lower IT costs.
Overview of DevOps
Core elements of DevOps
The core elements of DevOps can be summarized by the
acronym CALMS, which stands
for Culture, Automation, Lean, Measurement, and Sharing.
Culture
It encourages breaking down silos, promoting cross-functional
teamwork, and cultivating a shared sense of ownership and
responsibility for delivering high-quality software.
Automation
automating tasks such as build, testing, deployment, and
infrastructure provisioning, teams can achieve greater
efficiency, reduce errors, and accelerate software delivery.
Lean
That resources are optimized, processes are streamlined,
and activities that don’t add value are minimized or
eliminated.
Measurement
Measurement involves gathering and analyzing data to gain
insights into the performance and quality of software
development and delivery processes.
These metrics provide valuable feedback and enable
continuous improvement.
Sharing
sharing best practices, lessons learned, and
insights gained through experiences.
This facilitates learning, encourages innovation, and helps
teams align their efforts towards common goals..
Life cycle of DevOps
Adoption of DevOps
DevOps Tools
Build, Promotion and Deployment in DevOps
The DevOps way to deploy code is called CI/CD, which is short for
Continuous Integration and Continuous Deployment and
Continuous Delivery (yes, the CD stands for two different things).
When implemented well, CI/CD eases the deployment process
through a combination of good workflows and automation.
• Central availability of source code, almost always in version
control, that allows you to build the project from scratch.
• Frequent and incremental additions to the production version of
the code.
• Automation for carrying out the actual deployment.
• Automated testing on a pre-deployment version of the code.
CI/CD is all about quickly promoting code into production. It’s all
too easy to mess up production if you don’t have a clear boundary
between what is in production and what isn’t. That’s why software
environments are often divided into dev, test, and prod.