SOFTWARE DEVELOPMENT in 21 st century A BRIEF HISTORY GOALS MONOLITHS PRINCIPLES MICROSERVICES DEFINITION PAIN & PROMISES A TASTE OF MICROSERVICES TRADITIONAL ENTERPRISE ARCHITECTURES MONOLITHIC APP User Accounts Shopping Cart Product Catalog Customer Service Software Monolith • A Software Monolith • One build and deployment unit • One code base • One technology stack (Linux, JVM, Tomcat, Libraries) • • • • • Benefits Simple mental model for developers one unit of access for coding, building, and deploying Simple scaling model for operations just run multiple copies behind a load balancer MONOLITHIC DESIG • • • • • • • • • • Huge and intimidating code base for developers Development tools get overburdened Refactoring take minutes , builds take hours testing in continuous integration takes days Scaling is limited Running a copy of the whole system is resource-intense It doesn’t scale with the data volume out-of-the-box Deployment frequency is limited Re-deploying means halting the whole system Re-deployments will fail and increase the perceived risk of deployment • …. INTIMIDATES DEVELOPERS REQUIRES LONG-TERM COMMITMENT TO A TECHNOLOGY STACK OBSTACLE TO FREQUENT DEPLOYMENTS • Need to redeploy everything to change one component • Interrupts long running background (e.g. Quartz) jobs • Increases risk of failure Eggs in one basket Fear of Change • Updates will happen less often - really long QA cycles • e.g. Makes A/B testing UI really difficult Monolithic Apps – Failure & Availability COSA ABIAMO COMBINATO… What … have we done What are the Valued business drivers for the 21 st century ?! Better Cheaper Faster • Resilient • Technology choice • Test effort • Cost of maintaining • Change • Deployment • Execution Trends in software development ?!!! Platform as a Service Continuous Delivery Autonomous teams Agile Organization Reactive manifesto DDD BUILDING BLOCKS THE SCALE CUBE MICROSERVICES What do you think?!!! MICROSERVICES “building applications as suites of services. As well as the fact that services are independently deployable and scalable, each service also provides a firm module boundary, even allowing for different services to be written in different programming languages. They can also be managed by different teams” Martin Fowler MICROSERVICES • Small and focused on doing one thing well • Autonomous “Loosely coupled service oriented architecture with bounded contexts” Adrian Cockcroft (Netflix) “SOA done right” Anonymous “… services are independently deployable and scalable, each service also provides a firm module boundary, even allowing for different services to be written in different programming languages.” Martin Fowler (Thoughtworks) MICROSERVICES A way of designing software applications as suites of independently deployable services IT’ S NOT A SILVER BULLET Not suitable in many situations Be aware of your needs MICROSERVICE COMMON CHARACTERISTICS • • • • • • • • • • • • Single Responsibility Principle (SRP) Small Own process Valuable Replaceable Upgradeable Independent Encapsulated Composable Testable Fast startup/shutdown Client friendly MONOLITHIC VERSUS MICROSERVICES Monolithic Microservice Built as a single logical executable (typically the server-side part of a three tier client-server-database architecture) Built as a suite of small services, each running separately and communicating with lightweight mechanisms MODULARITY Based on language features Based on business capabilities AGILITY Changes to the system involve building and deploying a new version of the entire application Changes can be applied to each service independently Entire application scaled horizontally behind a load-balancer Each service scaled independently when needed Typically written in one language Each service implemented in the language that best fits the need MAINTAINABILITY Large code base intimidating to new developers Smaller code base easier to manage TRANSACTION ACID BASE ARCHITECTURE SCALING IMPLEMENTATION 51 << PRINCIPLES >> CROSS FUNCTIONAL TEAMS PROJECT MODEL DEVELOPMENT A-TEAM BUILD DEPLOY OPS-TEAM MAINTENANCE M-TEAM PRODUCT MODEL DEVELOPMENT BUILD A-TEAM DEPLOY MAINTENANCE MICROSERVICES PREREQUISITES • Before applying microservices, you should have in place • Rapid provisioning • Dev teams should be able to automatically provision new infrastructure • Basic monitoring • Essential to detect problems in the complex system landscape • Rapid application deployment • Service deployments must be controlled and traceable • Rollbacks of deployments must be easy Source http://martinfowler.com/bliki/MicroservicePrerequisites.html GUIDELINES FOR MICROSERVICES • Make each one focused – no real rule on size (“2 pizza teams”) • Each service should be treated like one app – Have its one SCM repo, own pipeline, etc • Should not require the use of other services • Service owners are responsible for the entire lifecycle • Use lightweight protocols • Use the right tool for the job • Each service should have its own datastore • Failure will happen, design for it • Automate everything MICROSERVICE CONCERNS Tooling Configuration Discovery Routing Observability Datastores Operational: Orchestration and Deployment Infrastructure Development: languages and container CHALLENGES CAN LEAD TO CHAOS IF NOT DESIGNED RIGHT … RESILIENT SYSTEM (Netflix way ) Embrace Chaos! “One of the first systems our engineers built in AWS is called the Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most – in the event of an unexpected outage.” http://luckyrobot.com/netflix-chaos-monkey-keeps-movies-streaming/ http://www.codinghorror.com/blog/2011/04/working-with-the-chaosmonkey.html Fallacies of Distributed Computing Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences. 1. 2. 3. 4. 5. 6. 7. 8. The network is reliable. Latency is zero. Bandwidth is infinite. The network is secure. Topology doesn’t change. There is one administrator. Transport cost is zero. The network is homogeneous. Peter Deutsch POSSIBLE MICROSERVICE ARCHITECTURE UI is resilient to failing or unavailable services Teams own UI as well User Interface Integration UI MS1 UI Choose appropriate technology per service Events Elements of Event Driven Architecture Async calls to MS2 other services MS3 Mostly resource based REST APIs UI MS4 Commands MS4 (Don’t) share database schema per partition All inter-service communication is asynchronous SCALING DEMO (IBM) IBM Example MONOLITH ARCHITECTURE App Client Side Code Sessions APIs Questions APIs Twilio Endpoint SMS/Email Service DB FAILURES IN A MONOLITH App Client Side Code Sessions APIs Questions APIs Twilio Endpoint SMS/Email Service DB SCALED MONOLITH App My App 1 Client Side Code Sessions API Questions API Twilio Endpoint Load Balancer SMS/Email Service My App App1 Client Side Code Sessions API Questions API Twilio Endpoint SMS/Email Service DB CLIENT FRAGILITY Sessions DB Client Side Code Sessions Service Questions DB Questions Service Reply Service Message Queue SendGrid Service Twilio Service MICROSERVICES ARCHITECTURE Sessions DB Client Side Code Sessions Service Questions DB Questions Service Reply Service Message Queue SendGrid Service Twilio Service API Gateways Sessions DB API Gateway Client Side Code Sessions Service Questions DB Questions Service Reply Service Message Queue SendGrid Service Twilio Service SCALING A SERVICE Sessions DB Sessions Service API Gateway Sessions Service Client Side Code Questions Service Questions DB Reply Service Message Queue SendGrid Service Twilio Service MORE QUESTIONS TO ANSWER … • How are all my microservices configured and is it correct? • What microservices are deployed and where? • How to keep up with routing information? • How to prevent chain of failures? • How to verify that all services are up and running? • How to track messages that flow between services? • How to ensure that only the API-services are exposed externally? • How to secure the API-services? That’s all folk • VIDEO YOUTUBE • From Mike Jones: https://www.youtube.com/watch?v=CKL3fV5 UR8w • • MICROSERVICE ARCHITECTURE http://microservices.io/index.html MICRSERVICES by James Lewis & Martin Fowler http://martinfowler.com/articles/microservices.html • MICROSERVICES ARE SOLID by Matt Stine http://www.mattstine.com/2014/06/30/microservicesare-solid/ • • MICROSERVICES JAVA , the UNIX way https://vimeo.com/74452550 MICROSERVICE ARCHITECTURE di Giuseppe Capodieci http://losviluppatore.it/microservices-architecture-il-pattern-architetturale-emergente-per-le-grandiapplicazioni-moderne/ • SLIDESHARE – MicroService Architecture by Fred George http://www.slideshare.net/fredgeorge/micro- service-architecure – A Gentle Introduction to Micro Services by Lemi Orhan Ergin http://www.slideshare.net/lemiorhan/a-gentle-introduction-to-micro-services-from-theory-intopractice – Mastering Chaos - A Netflix Guide to Microservices by Josh Evans • YouTube – – – – – – PRINCIPLES OF MICROSERVICES by Sam Newman MICROSERVICES by Martin Fowler CHALLENGES in IMPLEMENTING MICROSERVICES by Fred George THE STATE OF THE ART in MICROSERVICES by Adrian Cockcroft MICROSERVICES DAY: Microservices at Netflix by Diptanu Choudhury What are microservices and why would I want them? Mike jones
