Accelerate DevOps/Microservices and Kubernetes
•Descargar como PPTX, PDF•
2 recomendaciones•225 vistas
The business case for MicroServices, DevOps / Agile, adopting CI/CD, and Kubernetes with best practices.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Accelerate DevOps/Microservices and Kubernetes
Similar a Accelerate DevOps/Microservices and Kubernetes (20)
Más de Rick Hightower
Más de Rick Hightower (18)
Último
Último (20)
Accelerate DevOps/Microservices and Kubernetes
- 1. ACCELERATE AGILE DEVOPS / BUSINESS CASE FOR CI/CD, TDD, Microservices, K8s, AUTOMATION, ETC.
- 3. The promise of CI/CD and Agile/DevOps culture What we are after!
- 4. evOps, Continuous Deployment and Continuous Integration (CI/C Why we care?
- 5. ABOUT RICK• Author of best-selling agile development book, early adopter of TDD, DevOps, Agile, etc. • Highest leadership scores of any senior director in a 2,000 person org (happiest, most productive team). Highest performing team in a 1,000+ person group: Jenkins pipelines, Event Hub/EEL, High-code coverage, PR process, Trunk based git like GitHub flow, full automation, etc. • Two awards from CIO at fortune 500, amazing results (G.O.A.T and Engineering Excellence) • Amazing results finishing projects deemed impossible under tight deadlines. Grew team from 12 to 50+, Talent Magnet due to culture of excellence • Written open source software used by millions • Early adopter and proponent of MicroServices and streaming high-speed streaming, 12 factor deployment, container orchestration, in-memory compute and uService architecture • Speaker at conferences on microservice development, a Java Champion (chosen from 10,000,000 Java Developers), parsers, distributed data grids, books, articles, etc. • Mentoring, consulting, papers, blogs, specifications, JSRs for distributed compute, streaming
- 6. SLIDE DECK BASED ON BOOK ACCELERATE AND MORE• PAST EXPERIENCE • LATEST TRENDS
- 7. OUTLINE • How we got here • History of MicroServices • DevOps / Agile • CI/CD • Kubernetes • Best practices • Continuous delivery • Continuous integration • Lean management and monitoring / KPIs • SCM / Version Control / GitOps / Immutable infrastructure • Trunk-based development
- 8. BRIEF HISTORY OF MICROSERVICES AND AGILE,CI/CD Brief history of time
- 9. HOW WE GOT HERE • Web pages that were brochures • eCommerce • Legacy integration • Rush to Webify businesses • SOA: Wrap legacy systems as services to use from web • Virtualization, Virtualization2.0, Cloud, Containers, and now Container orchestration
- 10. “Now you can run a JVM in a Docker image which is just a process pretending to be an OS running in an OS that is running in the cloud which is running inside of a virtual machine which is running in Linux server that you don’t own that you share with people who you don’t know.” Microservices Architecture
- 11. “The Java EE container is no longer needed because servers are not giant refrigerator boxes that you order from Sun and wait three months for (circa 2000). Don’t fight classpath, classloader hell of Java EE. … your whole … OS is now an ephemeral container (Docker). Deliver an image with all the libs you need, don’t deploy to a Java EE server which has to be versioned and configured. You are only running one service in it anyway.… Let it go. …One issue with enterprise components is they assume the use of hardware servers which are large monoliths and you want to run a lot of things on the same server. Well, turns out in (today), that makes no sense. Operating systems and servers are ephemeral, virtualized resources and can be shipped like a component. We have EC2 images AMIs, OpenStack, Vagrant, Kubernetes and Docker. The world changed. Move on…. Microservices just recognize this trend so you are not developing like you did when the hardware, cloud orchestration, multi-cores, and virtualization was not there. You did not develop code in the 90s with punch cards did you? So don’t use an EAR file or a WAR file (today).” Microservices Architecture
- 12. MICROSERVICES • Focus is building small, reusable, scalable services • Adopt the Unix single purpose utility approach to service development • Small so they can be released more often and are written to be malleable • Easier to write • Easier to change • Go hand in hand with continuous integration and continuous delivery • Heavily REST based and messagingWhat is microservice architecture?Microservices Architecture
- 13. KEY INGREDIENT OF MICROSERVICES • independently deployable, small, domain-driven services • Own their data (no shared databases) • communication through a well-defined wire protocol usually JSON over HTTP (curl-able interfaces) • well defined interfaces and minimal functionality • avoiding cascading failures and synchronous calls - reactive designing for failure What is microservice architecture?
- 14. SOA VS. MICROSERVICES • SOA and Microservices have common goals and purposes • Refinement to meet goals of polyglot devices and 3rd generation virtualization (cloud, container, container orchestration) • Parts of SOA that worked well • MS: Web technologies to provide scalability, modular, domain-drive, small, and continuously deployable cloud-based services What is microservice architecture? It’s not the daily increase but daily decrease. Hack away at the unessential. -- Bruce Lee
- 15. SOA VS. MICROSERVICES “Microservices Architecture is taking what perhaps started out as SOA and applying lessons learned as well as pressure to support polyglot devices, deploy more rapidly and the architecture liquidity that cloud computing and virtualization/containerization provide. You mix all that together and you can see where Microservices Architecture started. Microservices Architecture is in general less vendor driven than SOA and more needs driven by demands of application development and current cloud infrastructure.” —Rick Hightower 2013 :)
- 16. UNIX PHILOSOPHY • Microservices compares to Unix philosophy, • Ken Thompson, Unix creator, said Unix has a philosophy of: one tool, one job • “Unix philosophy emphasizes building short, simple, clear, modular, and extendable code that can be easily maintained and repurposed by developers other than its creators” What is microservice architecture?
- 17. COPING WITH FAILURE • Avoid synchronous calls to avoid cascading failures • Microservices tend to embrace streams, queues, actor systems, event loops and other async calls • Spend more time with distributed logging / log aggregation w/ MDC and now distributed tracing
- 18. MICROSERVICES MONITORING • User Experience KPIs • Debugging (requests per second, #threads, #connections, failed auth, expired tokens, etc.) • Circuit Breaker (monitor health, restarts, act/react) • Cloud Orchestration (monitor load, spin up instances) • Health checks and observable KPIs "doveryai no proveryai" (trust, but verify) Microservice Monitoring
- 19. “Just remember Microservices are not a new thing, and they are not cool or hip. Microservices are obvious evolutionary architecture to address the revolutionary things that already happened: web, cloud, mobile, server virtualization, OS containerization, container orchestration, multi-core servers, cheaper and cheaper RAM, 64 bit computing, 10GBE, 100GBE, etc.” Microservices Architecture
- 20. MICROSERVICES ARE CONTINUOUSLY DEPLOYABLE SERVICES • Microservices focus on business capability, and a refocus on object oriented programming roots and organizing code around business domains with data and business rules co-located in the same process or set of processes
- 21. CONTINUOUSLY DEPLOYABLE MICROSERVICES• Focus of Microservices is on breaking up applications into small (micro) reusable services which might be useful to other services or other applications. • Services can be deployed independently • Each of these services to be tweaked, and then redeployed independently • This is where the "micro" part of microservices comes into play What is microservice architecture?
- 22. DEVOPS, AGILE, TDD, CI/CDBrief history of time
- 23. XP, AGILE, SCRUM, TDD, CI/CD • TDD, CI and CI/CD • Test Driven Development and Agile • XP, Agile, Scrum • CI/CD (Jenkins and the tools that came before) • CI/CD needs automated testing
- 24. DEVOPS • DevOps aka DevSecOps • Heroku and the birth of 12 factor deployment, DevOps, KPIs, SRE • YBYOI vs. SRE vs. DevOps and where do you fit? • SRE: Observability, Log aggregation, KPIs/Metrics, Distributed/Trace logging • Container Orchestration: Yarn, Mesos, Marathon, Nomad, Borg and Kubernetes • What is GitOps? What is immutable infrastructure? • What is cloud native?
- 25. KUBERNETES / K8S • Services, Stateful sets, Namespaces, Tags, Ingress, Egress • Helm/Kustomize for packaging an app or set of related uServices and deploy to K8s • Multi-cloud support and just cloud support • Monitoring built-in (or at least easily pluggable) • Easy to ramp up (or easier) • Supports flexible deployment models • Integrates with Cloud providers services or runs standalone (on prem or cloud) • What came before and now: Heroku/PaaS/IAAS/EC2, Docker, Docker Swarm, Mesos/Marathon, Nomad, ECS, EKS, etc. K8s is the current mindshare champ.
- 27. WINNING THE RACE Why we want to do it? Why it is important!
- 28. ACCELERATION IN PRACTICE • Make more money • Deliver more • Less Burnout • Grow the value of the company • Make customers happy
- 29. ORGANIZATIONAL PERFORMANCE • High performers 2x the rate will exceed organizational performance goals as low performers: • 2x profitability • 2x productivity • 2x market share • 2x number of customers
- 30. ORGANIZATIONAL PERFORMANCE PART II • High performers twice as likely to exceed non-commercial performance goals as low performers • 2x better quantity of products and services • 2x operating efficiency • 2x customer satisfaction • 2x quality of products/services • 2x achieving organizational/mission goals
- 31. ORGANIZATIONAL PERFORMANCE PART III 50% increase in market capitalization compared to low performers!
- 32. SOFTWARE DELIVERY PERFORMANCE • Deploy frequency, Lead time, mean time to restore (MTTR), and change fail percentage do well to predict overall software delivery performance • Improving software delivery performance improves tempo and stability • Software delivery performance improves organizational performance and quality/customer satisfaction • Deploy frequency is highly correlated with continuous delivery and use of version control best practices
- 33. SOFTWARE DELIVERY PERFORMANCE II • Lead time is highly correlated with good version control and automated testing • MTTR is highly correlated with version control and monitoring • Software delivery performance is negatively correlated with deployment pain • Software delivery performance is correlated with organizational investment in DevOps
- 34. QUALITY Source, Forsgren PhD, Nicole. Jez Humble, Gene Kim, Accelerate . IT Revolution Press. Kindle Edition. st amount of manual work across all practices - configuration m
- 35. CULTURE • 5 factors most associated with burnout are negatively impacted by bad software delivery performance • Deployment pain and poor software delivery practices cause organizational burnout
- 36. IMPROVE CULTURE BY IMPROVING PRACTICES• Technical practices predict continuous delivery • Improve organizational culture, identity, job satisfaction, software delivery performance, less burnout, less deployment pain, and less time spent on rework! • High performers spend 50% less time remediating security issues than low performers
- 37. TRUNK BASED DEVELOPMENT (LIKE GITHUB FLOW) • High performers have shortest integration times and branch lifetimes • Branch life and integration typically lasting hours or a day • Low performers have longest integration times and branch lifetimes • Branch life and integration typically lasting days or weeks
- 38. ARCHITECTURE • Loosely coupled, well-encapsulated architecture drives IT performance. • 2017 dataset biggest contributor to continuous delivery was loosely coupled, well-encapsulated architecture
- 39. LEAN PRODUCT MANAGEMENT CAPABILITIES• Experimental approach to product development highly correlates with continuous delivery • Lean product development capabilities predict improvements in organizational culture like reduced burnout higher software delivery performance and overall organizational performance
- 40. HOW WE GET THERE Rules of the road
- 41. ACCELERATE DEVOPS • Continuous delivery • Architecture • Product and process • Lean Management and monitoring • Cultural
- 42. CONTINUOUS DELIVERY CAPABILITIES 1. Implement continuous delivery / continuous deployment 2. Version control all production artifacts 3. Automate your deployment pipeline 4. Implement continuous integration 5. Use trunk-based development methods (like Github flow instead of git flow) 6. Implement test automation 7. Shift left on security
- 43. PRODUCT AND PROCESS CAPABILITIES • Gather and implement customer feedback • Make the flow of work through the system visible • Work in small batches • Foster and enable team experimentation
- 44. CULTURE CAPABILITIES • Support a generative culture • Encourage and support learning • Encourage collaboration • Make work as meaningful as possible • Support and encourage transformational leadership
- 45. ACCELERATE DEVOPS Source, Forsgren PhD, Nicole. Jez Humble, Gene Kim, Accelerate . IT Revolution Press. Kindle Edition.
- 46. ARCHITECTURAL CAPABILITIES TO ACCELERATE • Use loosely coupled architecture • Release new services on demand without outages • Empower the team to select tools; trust team to pick the best tools
- 47. LEAN MANAGEMENT AND MONITORING CAPABILITIES• Have a light weight change approval process • Monitor application and system KPIs to inform business decisions • Proactively check system health • Preemptively detect and mitigate problems • Improve process and work within WIP limits • Set up visible dashboards to monitor/communicate WIP, quality, applications and systems
- 48. EXAMPLE MONITORING • Hygieia • Productivity dashboards • Jenkins dashboards • Runtime KPIs • Customer KPIs
- 49. LEAN MANAGEMENT • Process: Small Batches • Decompose into features that allow for rapid development • MVP - prototype with just enough features to proved business value or enable validated learning • Quickly gather customer requirements (A/B testing, customer satisfaction surveys, etc.) • Team experimentation • Lean Management: Change approval • Lean Management: Proactive notification • Lean Management: Monitoring and KPIs • Lean Management: WIP limits, visualizing work
- 50. Companies with regulatory requirements or strict CCB Can focus on Continuous Delivery Continuous Deployment can be part of a workflow and Based on the Continuous Delivery
- 51. VERSION CONTROL - SCM • GitOps - keeping application code, system configuration, application configuration, and scripts for automating build and configuration in version control. • Factors together predict IT performance • Key component of continuous delivery • GitOps - keeping system and application config in git (versioned) correlates high with delivery performance
- 52. DEPLOYMENT AUTOMATION • Deployment automation • Containers, config, immutable infrastructure • Comprehensive configuration management (automation scripts), continuous integration and continuous testing • Key metric of GitOps is how much diffs exists in system config from git to deploy
- 53. CONTINUOUS INTEGRATION • Continuous integration • Relies on SCM and Deployment automation • Relies on automated tests • Unit • Integration • Acceptance
- 54. TRUNK-BASED DEVELOPMENT • Trunk-based development • Like GitHub Flow but shorter lived branches • Fewer active branches that never outlive a sprint • Branch-off master per feature, bug fix, etc. • More PRs more often • No code freezes; integration periods less than a day • Polar opposite of git flow
- 55. SHIFT LEFT ON SECURITY • Integrating security into design and testing phases • Security reviews of applications, including the infosec team in design and demo process • Using pre-approved security libraries and packages, and testing security features as a part of automated testing suite
- 56. CONTINUOUS DELIVERY • The ability to deliver • Build quality in • Work in small batches • Automate repetitive tasks including testing & deployments • Pursue continuous improvement • Ownership • Comprehensive configuration management • Continuous integration • Continuous testing You can’t skip steps. There is investment up front. Today’s speed up can be tomorrows painted yourself In a corner.
- 57. KNOWING THE ROAD Best practices
- 58. PREFER MICROSERVICES BUT… • Know when to employ Monolith and when not to • Can speed up MVP and prototypes but at a cost • Why this makes CI/CD slower? • Automated tests needed for CI/CD • Smaller Monoliths and SOA is a move in the right direction
- 59. PREFER MICROSERVICES • Refactoring to Microservices is a journey • Know when to employ Microservices • Fits the CI/CD well • Fits small batch well • How Micro can mean different things as you get better at Microservices • Why today's micro could be tomorrows Monolith? • Adoption is a Journey
- 60. EMBRACE OBSERVABILITY FROM THE START • Log aggregation • Time series data base • Log all KPIs for clusters • Log all KPIs for applications and services • Alerting • Know when and how to employ distributed tracing • Distributed/Trace logging
- 61. CI/CD • CI/CD • Deploy often (daily or more) • Test often (after every checkin run all automated tests) • Block PRs from merging until they pass tests
- 62. TESTS TO CREATE: TDD • Unit tests • Perf testing JMH • Functional tests • At the HTTP layer • At the Spring Boot layer • Acceptance tests • Smoke integration tests • Full integration tests • Synthetic testing • Code Coverage (sonarqube) • Security/Vulnerability dependency license checks • Aqua, Fortify • Full integration perf testing
- 63. WHAT IS A PR? AND HOW TO ENSURE QUALITY WITH IT• A PR is a pull-request • PR gives other developers a chance to review code before it committed to master • PR via small batch (why small? JIRA story or even a tasks or two) • With GitHub and WebHooks you can block PRs from merging • Code coverage met, build works, unit tests run, other checks via Jenkins • Review and approved by at least two people
- 64. TESTING IS A MUST! • You can't do CI/CD without automated testing • Testing allows you to move quickly with confidence
- 65. EMBRACE SMALL BATCH WORK • Goal of three PRs per week • Goal of one to two tasks from JIRA per PR • Use JIRA # in commits and PR comments
- 66. AUTOMATED DEPLOYMENT • Merging into master triggers a deploy to integration and sends a Team message • Approval from Product Manager pushes code to Prod or Demo • Checking into main branch from PR • Artifacts and scripts for deployment checked into git and should not be modified • Puts code staging area to be checked by Product Manager • into containers and deploys to cluster (some ephemeral some not) • Once checked by Infosec and Product Manager: Canary Deploys to 3 to 5% of traffic and is monitored (end goal) • Then more and more as it is monitored and is ok
- 68. THE RACE IS WON Conclusion
- 69. TRANSFORMATION IS A BUSINESS IMPERATIVE• You can’t afford not to transform • Transformation requires a deep understanding of practices • Having a team called DevOps is not doing DevOps per se • Culture of DevOps, Agility, Lean, MVP, etc. is a clear win • There are guides, books, practices, and information
- 70. Read Accelerate by Forsgren PhD, Nicole. Jez Humble, Gene Kim. Also read The Loop Approach: How to Transform your organization from The inside out! By Sebastian Klein and Ben Hughes Also read Cloud Native DevOps with Kubernetes by John Arundel and Justin Domingus
Notas del editor
- Rick Hightower Rick consults and does contract development for high-speed computing, Java-based uServices, Apache Spark, Apache Kafka, and Apache Cassandra. He also writes about microservice development and reactive streaming. Rick is a frequent speaker regarding high-speed, reactive microservice development and has spoken recently at JavaOne as well at FinTech at scale in SF. He specializes in high-speed, in-memory, non-blocking, microservices development which often includes Java EE, QBit, Reakt, Akka, Vert.x, Cassandra, Kafka, and cloud deployments. He has architected and implemented 100 million-users, in-memory content preference engines using Java reactive, streaming, and actor-based system as well as architected and implemented OAuth rate limiter (API gateway) for streaming music service to rate limit all backend services per partner/vendor/mobile app. Rick also contributed to the reference implementations enterprise caches as well as being a member of several spec. committees (JSR-347, JSR-107, etc.). He also is the author of the Boon JSON parser and parsing utilities which ships with Groovy.
- Enterprise Applications flashback While it is true Enterprise Applications are often built with a three tier architecture: backend code, database code and a GUI written in HTML/JavaScript. This has more to do with the world changing than an active choice. The real drivers for Microservices Architecture are cloud/virtualization/OS containerization, EC2, proliferation of mobile devices, cheaper memory, more virtualization, more cores, SSD, trend towards fatter clients, 10 GBE, 100 GBE, etc. The big enterprise web app is becoming obsolete to a certain extent at least for large applications. It is not like we one day came up with a better idea, and then one day we were like hey what if we could make our code more modular. The ground changed under our collective feet. The way we build, deploy, and consume has changed. Hardware evolved. Virtualization evolved. Containerization happened. Cloud computing became a real thing, and so compelling that it is hard to ignore. The smart phone / tablet / mobile revolution happened. Microservice is the response to these external events. Microservices and NoSQL are two trends that are more focused on how to address software development where deployments are increasingly cloud based and clients are increasingly mobile based. Just like you can’t compare client / server development of the mid-90s to mainframe development from the 70s, you can’t compare enterprise applications from 2001 to microservice development targeting mobile and web clients and other microservices in 2015. The world changes. We adjust. Microservice trend is course correction not a new religion. History of Enterprise Applications Remember 1990s, the reason why Enterprise Applications are written with three tiers was was to avoid DLL hell, and the monolith. We just did it with the tools available at the time. Back in the day, we used to build apps that were two tiered. You had to actually go to each users machine and help them install the app. There was a damn good chance they downloaded some shareware that installed a DLL that screwed up the install, and you were in hell. It was not like we were, “Hey James!” .. “What Martin?” “Do you want to build a huge monolith?” “Sure Martin!”. We tried Applets but Java GUI development back then sucked (1999). I don't think it sucks so bad now, but it lost its window of opportunity for adoption. Then we were left with HTML/JavaScript clients and forcing everyone to use the same browser in the corporation at least for the corporate apps. I worked at many corporations (2003) that banned JavaScript due to incompatibilities of browsers. You were left with screen painting with HTML. It was a like a colorful green screen of yesteryear, but way slower, but pretty. There are many reasons why this style of “Enterprise Development” does not work in the cloud and for mobile devices. The server-side applications no longer need to handle HTTP requests, get data from a database and execute all domain logic, and draw pretty pictures in HTML. Much pain, and great expense has been incurred trying get this three tier architecture to scale in the cloud for various devices written in a polyglot of languages. Microservices exists because mobile, cloud, cheaper RAM, cheaper disks, and improved virtualization. It is really just taking the world where it is. It is not revolutionary at all. Server components, EAR files and WAR files.. may they rest in peace If you have lived through COM, DCOM, CORBA, EJBs, OSGi, J2EE, SOAP, SOA, DCE, etc. then you know the idea of services and components is not a new thing, but they are a date expired concept for the most part. One issue with enterprise components is they assume the use of hardware servers which are large monoliths and you want to run a lot of things on the same server. That is why we have WAR files and EAR files, and all sorts of nifty components and archives. Well turns out in 2015 (and less so in 2019), that makes no sense. Operating systems and servers are ephemeral, virtualized resources and can be shipped like a component. We have EC2 images AMIs, OpenStack, Vagrant and Docker. The world changed. Move on. Microservices just recognize this trend so you are not developing like you did when the hardware, cloud orchestration, multi-cores, and virtualization was not there. You did not develop code in the 90s with punch cards did you? So don’t use an EAR file or a WAR file in 2015. Now you can run a JVM in a Docker image which is just a process pretending to be an OS running in an OS that is running in the cloud which is running inside of a virtual machine which is running in Linux server that you don’t own that you share with people who you don’t know. Got a busy season? Well then, spin up 100 more server instances for a few weeks or hours. This is why you run Java microservices as standalone processes and not running inside of a Java EE container. The Java EE container is no longer needed because servers are not giant refrigerator boxes that you order from Sun and wait three months for (circa 2000). Don’t fight classpath, classloader hell of Java EE. Hell your whole damn OS is now an ephemeral container (Docker). Deliver an image with all the libs you need, don’t deploy to a Java EE server which has to be versioned and configured. You are only running one service in it anyway. Turns out you don’t have five war files running in the same Java EE container since oh about 2007. Let it go. If you are deploying a WAR file to a Java EE container then you are probably not doing microservice development. If you have more than one WAR file in the container or an EAR file, then you are definitely not doing microservice development. If you are deploying your service as an AMI or docker container and your microservice has a main method, then you might be writing a microservice. Microservices architectures opt to break software not into components but into reusable, independently release-able services which run as one or more processes. Application and other services communicate with each other. So where we might have used a server side component, we use a microservice running in independent processes. Where we might have had WAR files or EAR files now we have a Docker container or a Amazon AMI that has the entire app preloaded and configure with exactly the libraries it needs (Java and otherwise). JSON, HTTP, WebSocket … NO WSDL! Now you just have to document the Microservices HTTP/JSON interface so other developers can call into it. We could say REST, and certainly you can use concepts from REST, but hey HTTP calls are enough to be considered a Microservice. Keep this in mind: No XML. No SOAP. No WSDL. No WADL. JSON! Ok you can add some meta data and document how to talk to your service, but the idea is the docs should be documented with curl. If you are only using SOAP or XML then you are not producing a microservice. JSON is a must. Documents should sound more like: I give you this request with these headers, params and JSON body and you respond with this JSON. Keep it simple. You can provide things in addition to JSON, but JSON is the minimum requirement. If you are not delivering up JSON and consuming JSON over HTTP or HTTP WebSocket then what you wrote is not probably not a microservice.
- Introduction To Microservices Microservice architecture is a method of developing software systems. Its focus is building small, reusable, scalable services. Applying Microservices becomes very important when you have to create services for polyglot devices: wearables, Internet of Things (IOT), mobile, desktop, and web. The trend towards providing services for rich, native mobile application and web applications started the trend towards Microservices adoption. This is one reason why microservices lean heavily on web technologies like HTTP/REST/WebSocket with JSON,Message Pack, and their ilk. The web technologies provide a low barrier to entry and least common denominator to communication. The closest to a standard definition of microservices is Microservices by James Lewis and Martin Fowler. … Continuous delivery: The microservices architectural approach is to create smaller services that are focused on a small business domain or crosscutting concern. Microservices adopt the Unix single purpose utility approach to service development. They are small so they can be released more often and are written to be malleable. They are easier to write. They are easier to change. Microservices go hand in hand with continuous integration and continuous delivery. The services are independent enough not to need a gigantic release train to release improvements or new features. In the Java world, this means you will be using other microservice like Jenkins to provide frequent releases.
- Key ingredients to microservices architecture are: independently deployable, small, domain-driven services communication through a well-defined wire protocol usually JSON over HTTP (curl-able interfaces) well defined interfaces and minimal functionality avoiding cascading failures and synchronous calls - reactive designing for failure
- This comes up a lot so let's address this now. It is very common for some to confuse Service-Oriented Architecture (SOA) and Microservice Architecture. In a sense, SOA and Microservice Architecture are related in some goals and purposes. Microservices is a refocus and refinement of some of the original goals of SOA to meet the demands of a polyglot device environment that can scale and support continuous deployments in a cloud / third generation virtualization environment. Since SOA was later muddled with BPEL, ESBs, SOAP, WSDL, and their ilk, it is easier to drop the SOA moniker and just focus on the parts that worked well. Keep the parts that work. Get rid of the rest. The focus on Microservices Architecture is web technologies to provide scalability, modular, domain-drive, small, and continuously deployable cloud-based services. Microservices Architecture is taking what perhaps started out as SOA and applying lessons learned as well as pressure to support polyglot devices, deploy more rapidly and the architecture liquidity that cloud computing and virtualization/containerization provide. You mix all that together and you can see where Microservices Architecture started. Microservices Architecture is in general less vendor driven than SOA and more needs driven by demands of application development and current cloud infrastructure. For more thoughts on SOA vs. Microservices read Microservices Architecture.
- Microservices Architecture is taking what perhaps started out as SOA and applying lessons learned as well as pressure to support polyglot devices, deploy more rapidly and the architecture liquidity that cloud computing and virtualization/containerization provide. You mix all that together and you can see where Microservices Architecture started. Microservices Architecture is in general less vendor driven than SOA and more needs driven by demands of application development and current cloud infrastructure.
- Cope with failure Microservices are designed to cope with failure. Since microservices tend to call each other, a downstream service that fails should not block upstream services and clients. Synchronous communication is avoided to avoid cascading failures. Thus Microservices tend to embrace async calls, streams, queues and actor systems. To handle failure, it is easier to embrace Queue theory so you can detect failure and provide alternatives or just fail gracefully without blocking clients. The ability to react to failure is a key characteristic of Microservices. In order to learn about downstream failure or learn about other functioning nodes and implement some sort of circuit breaker, one needs Service Discovery. Tools like consul, etcd and SkyDNSare perfect for Service Discovery. Adopting Microservices is not a free lunch. Steps to mitigate inherent complexity include distributed logging and MDC, microservices monitoring and stats, and reactive programming to coordinate async calls. The reactive call coordination would encompass what to do if there is a failure and what to do if a downstream service does not fail, but just times out or worse hangs.
- User Experience and Microservices Monitoring With Microservices which are released more often, you can try new features and see how they impact user usage patterns. With this feedback, you can improve your application. It is not uncommon to employ A/B testing and multi-variant testing to try out new combinations of features. Monitoring is more than just watching for failure. With big data, data science, and microservices, monitoring microservices runtime stats is required to know your application users. You want to know what your users like and dislike and react. Debugging and Microservices Monitoring Runtime statistics and metrics are critical for distributed systems. Since microservices architecture use a lot of remote calls. Monitoring microservices metrics can include request per second, available memory, #threads, #connections, failed authentication, expired tokens, etc. These parameters are important for understanding and debugging your code. Working with distributed systems is hard. Working with distributed systems without reactive monitoring is crazy. Reactive monitoring allows you to react to failure conditions and ramp of services for higher loads. Circuit Breaker and Microservices Monitoring You can employ the Circuit Breaker pattern to prevent a catastrophic cascade, and reactive microservices monitoring can be the trigger. Downstream services can be registered in a service discovery so that you can mark nodes as unhealthy as well react by reroute in the case of outages. The reaction can be serving up a deprecated version of the data or service, but the key is to avoid cascading failure. You don't want your services falling over like dominoes. Cloud Orchestration and Microservices Monitoring Reactive microservices monitoring would enable you to detect heavy load, and spin up new instances with the cloud orchestration platform of your choice (EC2, CloudStack, OpenStack, Rackspace, boto, etc.).
- Continuously deployable services The focus on Microservices is a focus on business capability, and a refocus on object oriented programming roots and organizing code around business domains with data and business rules co-located in the same process or set of processes. The focus is on breaking up applications into small reusable services which might be useful to other services or other applications. The services can be deployed independently. This allows each of these services to be tweaked, and then redeployed independently. This is where the "micro" part of microservices comes into play. The services are small and independent. This is where microservices have been compared to Unix philosophy, they provide services that handle requests and give responses. Ken Thompson, Unix creator, said Unix has a philosophy of one tool, one job. The Unix philosophy emphasizes building short, simple, clear, modular, and extendable code that can be easily maintained and repurposed by developers other than its creators.
- Forsgren PhD, Nicole. Accelerate . IT Revolution Press. Kindle Edition.
- High performers are twice as likely to exceed organizational performance goals as low performers: profitability, productivity, market share, number of customers. Forsgren PhD, Nicole. Accelerate . IT Revolution Press. Kindle Edition.
- High performers are twice as likely to exceed noncommercial performance goals as low performers: quantity of products/ services, operating efficiency, customer satisfaction, quality of products/services, achieving organizational/mission goals. Forsgren PhD, Nicole. Accelerate . IT Revolution Press. Kindle Edition.
- In a follow-up survey to the initial 2014 data collection effort, we gathered stock ticker data and performed additional analysis on responses from just over 1,000 respondents across 355 companies who volunteered the organization they worked for. For those who worked for publicly traded companies, we found the following (this analysis was not replicated in later years because our dataset was not large enough): –High performers had 50% higher market capitalization growth over three years compared to low performers. Forsgren PhD, Nicole. Accelerate . IT Revolution Press. Kindle Edition.
- The four measures of software delivery performance (deploy frequency, lead time, mean time to restore, change fail percentage) are good classifiers for the software delivery performance profile. The groups we identified—high, medium, and low performers—are all significantly different across all four measures each year. Our analysis of high, medium, and low performers provides evidence that there are no trade-offs between improving performance and achieving higher levels of tempo and stability: they move in tandem. Software delivery performance predicts organizational performance and noncommercial performance. Forsgren PhD, Nicole. Accelerate . IT Revolution Press. Kindle Edition.
- Lead time is highly correlated with version control and automated testing. MTTR is highly correlated with version control and monitoring. Software delivery performance is correlated with organizational investment in DevOps. Software delivery performance is negatively correlated with deployment pain. The more painful code deployments are, the poorer the software delivery performance and culture. Forsgren PhD, Nicole. Accelerate . IT Revolution Press. Kindle Edition.
- Unplanned work and rework: –High performers reported spending 49% of their time on new work and 21% on unplanned work or rework. –Low performers spend 38% of their time on new work and 27% on unplanned work or rework. –There is evidence of the J-curve in our rework data. Medium performers spend more time on unplanned rework than low performers, with 32% of their time spent on unplanned work or rework. Manual work: –High performers report the lowest amount of manual work across all practices (configuration management, testing, deployments, change approval process) at statistically significant levels. –There is evidence of the J-curve again. Medium performers do more manual work than low performers when it comes to deployment and change approval processes, and these differences are statistically significant. Forsgren PhD, Nicole. Accelerate . IT Revolution Press. Kindle Edition.
- BURNOUT AND DEPLOYMENT PAIN: Deployment pain is negatively correlated with software delivery performance and Westrum organizational culture. The five factors most highly correlated with burnout are Westrum organizational culture (negative), leaders (negative), organizational investment (negative), organizational performance (negative), and deployment pain (positive). Forsgren PhD, Nicole. Accelerate . IT Revolution Press. Kindle Edition.
- Trunk-based development: –High performers have the shortest integration times and branch lifetimes, with branch life and integration typically lasting hours or a day. –Low performers have the longest integration times and branch lifetimes, with branch life and integration typically lasting days or weeks. Technical practices predict continuous delivery, Westrum organizational culture, identity, job satisfaction, software delivery performance, less burnout, less deployment pain, and less time spent on rework. High performers spend 50% less time remediating security issues than low performers. Forsgren PhD, Nicole. Accelerate . IT Revolution Press. Kindle Edition.
- A loosely coupled, well-encapsulated architecture drives IT performance. In the 2017 dataset, this was the biggest contributor to continuous delivery. Forsgren PhD, Nicole. Accelerate . IT Revolution Press. Kindle Edition.
- LEAN PRODUCT MANAGEMENT CAPABILITIES The ability to take an experimental approach to product development is highly correlated with the technical practices that contribute to continuous delivery. Lean product development capabilities predict Westrum organizational culture, software delivery performance, organizational performance, and less burnout. Forsgren PhD, Nicole. Accelerate . IT Revolution Press. Kindle Edition. Forsgren PhD, Nicole. Accelerate . IT Revolution Press. Kindle Edition.
- Forsgren PhD, Nicole. Accelerate . IT Revolution Press. Kindle Edition.
- Forsgren PhD, Nicole. Accelerate . IT Revolution Press. Kindle Edition.