Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
Salesforce: CI,CD & CT
Salesforce: CI,CD & CT
Loading in …3
×
1 of 22

Architecting DevOps Ready Application

0

Share

Architecting DevOps Ready Application by "Rupesh Kumar Agrawal" from "BMC". The presentation was done at #doppa17 DevOps++ Global Summit 2017. All the copyrights are reserved with the author

Related Books

Free with a 30 day trial from Scribd

See all

Architecting DevOps Ready Application

  1. 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
  2. 2. Traditional Application Architecture
  3. 3. Emergence of DevOps
  4. 4. #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
  5. 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) 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.
  6. 6. Monolith Vs Microservices
  7. 7. #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
  8. 8. 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
  9. 9. Micro services Design … • Define REST endpoints, with required flexibility only • Make Sure there are SPOFs • Establish a service registration and discovery infrastructure (Easier Loadbalancing)
  10. 10. Micro services Design • Containerize the services • Docker with Kuberneties • Make Sure there are SPOFs • Establish a service registration and discovery infrastructure
  11. 11. #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
  12. 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 • 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.
  13. 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) 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.
  14. 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) 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.
  15. 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) Q & A Thank You
  16. 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) 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.
  17. 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) 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.
  18. 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) 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.
  19. 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) 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.
  20. 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) 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.
  21. 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) Other ones to know about

Editor's Notes

  • 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.
  • ×