The document discusses architecting applications for DevOps. It begins by describing traditional monolithic architectures and their limitations in scaling. It then introduces microservices as an alternative architecture that is more modular, independent, and scalable. The key advantages of microservices like ease of deployment, reliability, and scalability are discussed. The document provides guidance on designing microservices to be independent, have separate data stores, and use containers. It argues that microservices and DevOps principles like continuous integration/delivery work well together by simplifying deployment and maintenance. The document concludes by discussing how microservice architectures can better handle sudden traffic surges using DevOps tools and cloud platforms.
Breaking the Kubernetes Kill Chain: Host Path Mount
Architecting DevOps Ready Application
1. #DOPPA17
As a author of this presentation I/we own the copyright and confirm the originality of the content. I/we allow Agile testing alliance to use the content for social media
marketing, publishing it on ATA Blog or ATA social medial channels(Provided due credit is given to me/us)
#DOPPA17
Architecting DevOps ready application
Rupesh Kumar Agrawal
9th September 2017
5. #DOPPA17
As a author of this presentation I/we own the copyright and confirm the originality of the content. I/we allow Agile testing alliance to use the content for social media
marketing, publishing it on ATA Blog or ATA social medial channels(Provided due credit is given to me/us)
Monolithic bane
• Difficult to react to a business situation
A surge on search request volume require to scale up
the complete webserver, to meet the demands,
unnecessarily eating up the resources.
• Scaling-up requires scaling across the
application and layers
6. #DOPPA17
As a author of this presentation I/we own the copyright and confirm the originality of the content. I/we allow Agile testing alliance to use the content for social media
marketing, publishing it on ATA Blog or ATA social medial channels(Provided due credit is given to me/us)
Which is
• Bulkier
• Riskier
• Plan to Fail
• Not vertically scalable.
– As one of the subcomponent will hold back the
other ones.
Tightly coupled modules, which cannot operate
independently.
8. #DOPPA17
As a author of this presentation I/we own the copyright and confirm the originality of the content. I/we allow Agile testing alliance to use the content for social media
marketing, publishing it on ATA Blog or ATA social medial channels(Provided due credit is given to me/us)
Micro services advantages
– Easy Deployment
– Reliable
– Available
– Scalable
– Selective
– Manageable
9. Micro services Design…
• Divide functionally ,focused towards the
way its needs to be consumed
• Map and design the services to be
independent
• Have Separate Data Stores , which is
denormalized
10. Micro services Design …
• Define REST endpoints, with required
flexibility only
• Make Sure there are SPOFs
• Establish a service registration and discovery
infrastructure (Easier Loadbalancing)
11. Micro services Design
• Containerize the services
• Docker with Kuberneties
• Make Sure there are SPOFs
• Establish a service registration and discovery
infrastructure
12. #DOPPA17
As a author of this presentation I/we own the copyright and confirm the originality of the content. I/we allow Agile testing alliance to use the content for social media
marketing, publishing it on ATA Blog or ATA social medial channels(Provided due credit is given to me/us)
Micro services and DevOps
• DevOps and micro services work better when applied
together
• Containerised Services
– Simple to maintain DevOps env,
– Each once of them can be treated equally
• With a single script handling all of them
• Easier Adoption of CI and CD principles
– Micro services + DevOps = Agility
13. #DOPPA17
As a author of this presentation I/we own the copyright and confirm the originality of the content. I/we allow Agile testing alliance to use the content for social media
marketing, publishing it on ATA Blog or ATA social medial channels(Provided due credit is given to me/us)
Micro services and DevOps
• Not only deployment and maintenance it also
simplifies the delivery and Integration of the
product easier
• Micro services can increase teams velocity,
together with the CI and CD practices
• They complement the cloud-based application
architecture, by supporting event driven
programming and auto-scale scenarios.
14. #DOPPA17
As a author of this presentation I/we own the copyright and confirm the originality of the content. I/we allow Agile testing alliance to use the content for social media
marketing, publishing it on ATA Blog or ATA social medial channels(Provided due credit is given to me/us)
Handling a sudden surge
• Micro services can be spawned on demand,
– utilizing a sophisticated DevOps infrastructure in place and
– brought down once the spike in gone, and
– hence utilizing the resources in best way on a Cloud platform .
• This makes sure that only the required services are
multiplied
– and only the required minimum infrastructure is consumed (and
hence billed on a Cloud Platform).
• Containerization removes the dependency on the target
platform,
– and reinforces the system of any failure due to 3rd party
mismatches , and hence more robust.
15. #DOPPA17
As a author of this presentation I/we own the copyright and confirm the originality of the content. I/we allow Agile testing alliance to use the content for social media
marketing, publishing it on ATA Blog or ATA social medial channels(Provided due credit is given to me/us)
Conclusion
As we discussed the Applications lifecycles have
come a long way with symbiotic growth of the
architectural practices and the deployment
practices , complementing each other, leading to
ever robust, fault-tolerant and scalable systems.
16. #DOPPA17
As a author of this presentation I/we own the copyright and confirm the originality of the content. I/we allow Agile testing alliance to use the content for social media
marketing, publishing it on ATA Blog or ATA social medial channels(Provided due credit is given to me/us)
Q & A
Thank You
17. #DOPPA17
As a author of this presentation I/we own the copyright and confirm the originality of the content. I/we allow Agile testing alliance to use the content for social media
marketing, publishing it on ATA Blog or ATA social medial channels(Provided due credit is given to me/us)
Tools at disposal
• Following slides introduces a set of tools once
can find handy while starting with micro
service/DevOps transformation .
• This is an ever evolving and chances are there
are a few added to this list, by the time we
discuss this.
18. #DOPPA17
As a author of this presentation I/we own the copyright and confirm the originality of the content. I/we allow Agile testing alliance to use the content for social media
marketing, publishing it on ATA Blog or ATA social medial channels(Provided due credit is given to me/us)
Consul
• A Service discovery and registration Platform
• It has an agent which lies on a node and keeps
a tab of the health of the node and the health
of the services installed on it.
• Can be configured under a load balancer
which will reach it to get a pool of healthy
nodes available to serve a flow.
19. #DOPPA17
As a author of this presentation I/we own the copyright and confirm the originality of the content. I/we allow Agile testing alliance to use the content for social media
marketing, publishing it on ATA Blog or ATA social medial channels(Provided due credit is given to me/us)
Docker
• Containerization platform for the
microservices,
• Helps providing a common way to handle the
services, and hence simplifies the devops
infrastructure to a great extent.
20. #DOPPA17
As a author of this presentation I/we own the copyright and confirm the originality of the content. I/we allow Agile testing alliance to use the content for social media
marketing, publishing it on ATA Blog or ATA social medial channels(Provided due credit is given to me/us)
Ansible
• A simple ssh script language which helps
execute the ssh commands on remote
machines, hence performing the devops tasks
on a heard of machines.
21. #DOPPA17
As a author of this presentation I/we own the copyright and confirm the originality of the content. I/we allow Agile testing alliance to use the content for social media
marketing, publishing it on ATA Blog or ATA social medial channels(Provided due credit is given to me/us)
Drop wizard
• A bundle of tool which greatly simplifies the
Micorservices development, it provides all the
required bundles of SW to develop a service in
a lightweight package.
22. #DOPPA17
As a author of this presentation I/we own the copyright and confirm the originality of the content. I/we allow Agile testing alliance to use the content for social media
marketing, publishing it on ATA Blog or ATA social medial channels(Provided due credit is given to me/us)
Other ones to know about
Notas del editor
UI layer
A webserver
A processing layer (Application)and
DB and other persistence and data layers
All of the application logic was bundled inside the Application/webserver layer.
More focussed on the technical aspect of the system
Tight coupling , feed all or none
No selective scaling of a sub-component
Everything in a Single Package
On-premise and Monolithic
Unmanageable Sub-components
No clear boundaries of responsibility
Tight coupling
Higher chances of complete roll back due to deployment failure
Difficult to put on cloud and utilise DevOps practices to best extents
Helped Automate the application deployment and maintenance
The setup steps can be replayed exactly across multiple deployments
Eventually leading to reliable and reproducible system deployments
Application with traditional architecture, do not take full advantage of the devops techniques, leading to deployments which are not business ready.
Architectural Pattern to develop an application composed of loosely coupled, independent modules with separate business functions, communicating over the Web interface, mostly REST layer.
These services are developed , deployed and scaled independently leading to shorter TTM and faster reaction time for a business situation.
Open Close Principal:
Open for extension(via interfaces) , Closed for modification
Easy Deployment : Being independent and self sufficient, they are a good candidate for easier deployment.
Reliable: limited scope of fault, unlike the monolith where everything fails with a single failure
Available : smaller time for a refresh , which in independendent and scope limited
Scalable : being smaller and targeted we know what is getting scaled own or Up . It also, fits the cloud paradigm, where the each bit of resource counts.
Selective: Making use of a central lookup registry like mechanisms(e.g. Consul), it’s easier to scale a selected service without affecting any other of the services.
Manageable : Micro services pave the way for agility, with each service being independently developed and managed, making it easier to move faster.
No SPOFs, Failure in one service should not crash or impact other parts of the application.
Could be scaled up independently
So that it can be easily replaced with , if required.
A REST service ingesting data into the system, is an example of stateless service, which can be independently scaled , based of change in load.
These services should be containerized, with technologies like Docker, which can further utilise Kuberneties
Should also, utilise some service registration and discovery service for making life of load balancers easier.