Elastically scalable architectures with microservices. The end of the monolith?
•Download as PPTX, PDF•
5 likes•2,574 views
In the last years the microservices architecture style has been gaining traction with some companies such as Netflix, Yelp, Gilt, PayPal. Many of that companies abandoned their previous monolithic architecture and moved to a microservices approach. Does that mean that monolithic architectures are a thing of the past? In this talk we will review some key microservices concepts (and misconceptions), search for the essence of microservices architectures and discuss about different approaches to implement them from the industry.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Elastically scalable architectures with microservices. The end of the monolith?
Similar to Elastically scalable architectures with microservices. The end of the monolith? (20)
More from Javier Arias Losada
More from Javier Arias Losada (7)
Recently uploaded
Recently uploaded (20)
Elastically scalable architectures with microservices. The end of the monolith?
- 1. The end of the monolith? Elastically scalable architectures with microservices.
- 2. Monolithic architecture Feel the pain intro Netflix, PayPal, Twitter, Amazon… What do they have in common? Are monolithic architectures dead? Distributed architecture with smaller services
- 3. about me Javier Arias, senior software engineer at Telefonica. Working during last year with a microservices in EyeOS, helping to create an VDI (Virtual Desktop Infrastructure) platform. @javier_arilos http://about.me/javier.arilos
- 4. Back to the question Objective: To discuss about microservices concepts & misconceptions Are monolithic architectures dead?
- 5. A brief history of architectures Mainframes, Client/server (2 and then 3 tiers) SOA Microservices
- 6. Mainframe, Client/Server, SOA, Microservices… They tried to solve architectural problems And the history repeats but… there is no silver bullet
- 9. Cloud and containers The catalysts (II)
- 10. Continuous Integration and Delivery Automate QA and Deployment, Feedback The catalysts (III)
- 11. Microservices And we, software engineers are fashion victims. Microservices are trendy, since 2014.
- 12. Microservices definition Loosely coupled service oriented architecture with bounded contexts. (Adrian Cockcroft)
- 13. Loosely coupled released & upgraded independently no shared database avoid complex middlewares (SOA)
- 14. service oriented architecture run as standalone processes talk via APIs, semantic versioning
- 15. with bounded contexts size & responsibilities matter a lot. organized around business capabilities Domain Driven Design & bounded contxts
- 17. microservice anatomy persistence & language spoiled by choice? be careful when adding technologies
- 18. microservices talking to microservices API + lightweight communications HTTP vs lightweight message bus
- 19. are your microservices good citizens? stateless: key for scalability failure ready: death or dependency failure idempotent: repeated reqs yield same result operations ready: logging, correlation...
- 20. we know how to develop microservices
- 21. microservices are dynamic services start / stop all the time where are my services? service discovery DNS vs Database Query failure detection
- 22. scaling microservices: stateless, discoverable manual scale is boring let’s go dynamic how we decide on scaling? Information, from: servers channel
- 23. still awake? please wake up your buddies around! just 10 slides to go… :-)
- 24. monolith vs microservices: the essence deploy many collaborating processes vs deploy single platform of components
- 25. simpler to deploy more difficult to scale, specially deployment monolith vs microservices: deploy more complexity scales better (software, teams and deployment) microservices: many processes 2 deploy monolith: one single ‘thing’ 2 deploy
- 26. prone to coupling: code, database in-process calls much easier to refactor and test monolith vs microservices: distributed computing decoupled by deployment distributed computing is hard: failure-ready, many moving parts, testing microservices: distributed computing monolith: no distributed computing
- 27. consistency, simpler operations are simpler monolith vs microservices: platform best tool for the job, more freedom, more complexity operations are more complex microservices: many technoligies monolith: constrained technologies
- 28. size cost microservices monolith New project: monolith or microservices? WHY DON’T WE FOLLOW THE HAPPY PATH?
- 30. wrong monolith what is really wrong with monoliths? bad designed monoliths
- 31. well designed monoliths lower coupling, design for change DDD with bounded contexts API: Facade Design Pattern No database sharing
- 32. size cost microservices monolith can we now follow the happy path?
- 33. remember... whatever your problems are... there is no silver bullet
- 34. references
- 35. talk abstract In the last years the microservices architecture style has been gaining traction with some companies such as Netflix, Yelp, Gilt, PayPal. Many of that companies abandoned their previous monolithic architecture and moved to a microservices approach. Does that mean that monolithic architectures are a thing of the past? In this talk we will review some key microservices concepts (and misconceptions), search for the essence of microservices architectures and discuss about different approaches to implement them from the industry, including how we implemented it in EyeOS.
Editor's Notes
- What do Netflix, Yelp, Gilt, PayPal, Twitter, Amazon and others have in common? they started with a monolithic architecture, they are very successful companies and needed to scale: software, teams and do agile deployments they started to feel pain by being blocked, by the architecture to scale and deploy. they broke their monoliths into a distributed architecture with smaller services to release the pain Are monoliths obsolete? Are monoliths a thing of the past?
- Are monoliths obsolete? Are monoliths a thing of the past? The objective of the talk is to show the main concepts and misconceptions about microservices versus monoliths.
- MAINFRAMES huge iron servers, server room, all applications in the same host, users were able to access the mainframe via "dumb terminals" 1950s mainframes begin to be available to big corporations and schools in the 1970s, IBM released an operating system called VM that allowed admins on their System/370 mainframe systems to have multiple virtual systems, or "Virtual Machines" (VMs) on a single physical node NASA shutted down its last mainframe in 2012, but probably, many of the your money transactions are still safely executed and stored in mainframes. CLIENT/SERVER as PCs improved their power, the idea to move processing capacity to the client started to catch on. Client/server came in two flavors: 2 tiers, where local PCs run applications that connect to the shared database or even mainframe (mixing behaviour and database). 3 tiers, client, application server running the application, database. SOA SOA means so many different things to different people. For some SOA is about exposing software through web services For some SOA implies an architecture where applications disappear, core services that supply business functionality and data separated by UI aggregators that apply presentations that aggregate together the stuff that core services provide For some SOA is about allowing systems to communicate over some form of standard structure (usually XML based) (CORBA with angle brackets) For some SOA is all about using (mostly) asynchronous messaging to transfer documents between different systems. Essentially this is EAI MICROSERVICES Microservices could be seen as a subset of SOA where many of the ambiguity is removed.
- CHEMISTRY. a substance that causes or accelerates a chemical reaction without itself being affected. INTRO: When talking about microservices architectures, we must talk not only about technology, but also about the complete software development cycle. AGILE: Agile software development and agile (or lean) product management, bring shorter release cycles, faster time-to-market, and more frequent small changes. CONTAINERS: Cloud and containers allow easiest application deployment, and programmable infrastructure (eg. elastically scale, single-use test environments…) CONTINUOUS INTEGRATION: Continuously merging code to main branch combined to automated tests (unit, integration, end to end, performance) in a pipeline makes that software at the end of the process may be deployed to production at any moment.
- CHEMISTRY. a substance that causes or accelerates a chemical reaction without itself being affected. INTRO: When talking about microservices architectures, we must talk not only about technology, but also about the complete software development cycle. AGILE: Agile software development and agile (or lean) product management, bring shorter release cycles, faster time-to-market, and more frequent small changes. CONTAINERS: Cloud and containers allow easiest application deployment, and programmable infrastructure (eg. elastically scale, single-use test environments…) CONTINUOUS INTEGRATION: Continuously merging code to main branch combined to automated tests (unit, integration, end to end, performance) in a pipeline makes that software at the end of the process may be deployed to production at any moment.
- CHEMISTRY. a substance that causes or accelerates a chemical reaction without itself being affected. INTRO: When talking about microservices architectures, we must talk not only about technology, but also about the complete software development cycle. AGILE: Agile software development and agile (or lean) product management, bring shorter release cycles, faster time-to-market, and more frequent small changes. CONTAINERS: Cloud and containers allow easiest application deployment, and programmable infrastructure (eg. elastically scale, single-use test environments…) CONTINUOUS INTEGRATION: Continuously merging code to main branch combined to automated tests (unit, integration, end to end, performance) in a pipeline makes that software at the end of the process may be deployed to production at any moment.
- Continuous Integration is a software development practice where members of a team integrate their work frequently into the main branch of the Version Control System, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Automatic build steps: unit tests code quality metrics package (eg: create RPM, Docker container, Virtual Machine) component, integration, end2end, performance tests Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.
- There is no single definition, and it depends on who you speak to. My current favorite is the definition from Adrian Cockcroft, who is the architect behind Netflix migration to microservices architecture. Loosely coupled service oriented architecture with bounded contexts. (Adrian Cockcroft)
- There is no single definition, and it depends on who you speak to. My current favorite is the definition from Adrian Cockcroft, who is the architect behind Netflix migration to microservices architecture. Loosely coupled service oriented architecture with bounded contexts. (Adrian Cockcroft)
- The main treat of loosely coupled services is the fact that they can be released and upgraded independently. Shared databases was used frequently in the past to integrate different applications. It is one of the worst forms of coupling and forces to be very careful when making any change to the data or its schema. In microservices, each microservice cares about a little responsibility, and owns its data. No access to the domain managed by the microservice can be done if not done using APIs Other sources of coupling can be shared libraries. During the SOA fever, many middleware vendors proposed to add a coordination layer between applications. That layer would be responsible of many data transformations, routing, coordination of processes… and even some business logic. The result is that delivering new functionalities is coupled to many more pieces, making it much more difficult.
- Each microservice run as a standalone process, this can lead to horizontal scalability, given the All microservices talk exclusively using APIs, no database sharing. This reduces coupling, but we still have services coupled by the API. When changing the API we can break everything or be forced to deploy different services at the same time. Semantic versioning helps reduce (not avoid) this problems. In semantic versioning we use the different tokens in the version (eg: 2.3.23) to represent the impact of the changes in the API, from right to left: patch changes (bugfixing), minor changes (new functionalities), major changes (incompatible API changes). Semantic versioning and microservices running as standalone processes help to design strategies for migrating APIs to major version releases (eg: having different versions running at the same time while migrating dependent services).
- SIZE: Size is very important when talking about microservices. Microservices should have a size so that it is manea egarding size, there is some controversy here. Some sources insist in defining microservices by the number of Lines of Code (LOC), but this is arbitrary and a non-sense. The key point is HOW DO YOU DECIDE WHAT RESPONSIBILITIES BELONG TO A PARTICULAR SERVICE? A service must specialize in do one thing and do it well. When it needs help, talks to other microservices by using their APIs. Microservices should be organized by responsibility, domain or business capability. Eric Evans in DDD (Domain Driven Design) talks about designing domain models as a very important part. When designing a system, the business model must reflect the reality: Customer, Bill, Product, Stock, Payment, … but in complex systems there are different realities. The same entity, eg: Customer has different properties in different contexts: eg departments of marketing, finance, logistics. DDD defines BOUNDED CONTEXTS as a way to split big domain models in sets of entities that are significant in a given context (eg. finance department). Different contexts may have completely different models for common concepts with mechanisms to map between these polysemic concepts for integration. SIZE AND CHATTY APIS: You must strike a balance here. If you fragment too much, cohesion of your application is too low, APIs are too chatty and you need too many interactions between microservices to do just one thing. If you make services too big, you risk to couple too much functionalities together.
- PERSISTENCE AND LANGUAGE: one advantage of microservices is that each one is a standalone process that is independently developed, tested, released and operated. Each microservice uses its own data storage backend(s). Using different databases for different purposes is known as Polyglot Persistence. This means that services can be developed using different programming languages and use different data storages. While this is stated as an advantage of microservices over monolithic architectures, we must be careful here. Finding a balance between finding the best tool for the job and introducing more complexity by using many different technologies. I read an article some time ago that stated that when you develop an application you have a small number of tokens for investigation and problems. If you choose technologies that are immature or inestable you lose some of your tokens. The nice thing about boring technologies is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood. When you choose a new technology, you are putting more stress in many aspects:operations, learning curve. You have to monitor the thing. You have to figure out unit tests, if it is a DB create and maintain a cluster, ...
- Smart endpoints and dumb pipes: no intelligence should go into the communication mechanism (avoid ESB approach) * Two main communication mechanisms: HTTP request response and lightweight message bus * In a monolith components call each other via method invocation. A big issue migrating to microservices is converting to coarser grained APIs or end with chatty communications.
- Other important characteristics of microservices: STATELESS: Being stateless mean that they do not keep any state inside. Stateless services only need the information in a request to handle it. Of course, for handling requests we will need to query databases or talk to other services, but no state is kept outside of the databases. Statelessness implies that services can be started/stoppped at any moment without any risk, and that all requests can be load balanced between different service instances to improve scalability. IDEMPOTENT: repeated operations should yield the same result, or at least be prepared to receive repeated operations without failing. FAILURE READY: our microservices should be prepared to not lose operations in case of death or failure of a dependency (eg mongodb, redis, …) EXAMPLE, if a request makes different two changes to a database and the process fails between first and second, our platform should ensure that we will receive the same request again later. A simple way of achieving this is using some message broker like RabbitMQ and manual Acknowledge of messages. If a process fails without acknowledge, it is requeued and delivered to another consumer. When a brother process receives the request, repeats the first operation and it must not fail (Eg do upsert instead of insert, go on on duplicated...), then finish with the second operation and confirm the message in RabbitMQ GOOD CITIZENS: there are many other small features that are very important in microservices architectures. (Eg do upsert instead of insert, go on on duplicated...)
- Let’s talk about other important aspects about microservices
- With microservices, the execution environment is very dynamic, microservices can be started or stopped at any time. An important question arises: WHERE ARE MY SERVICES? service discovery helps you have such a dynamic environment and be able to know the addresses of your services. In EyeOS we are using consul.io Discovering our services comes in two flavours: DNS: our services know the name of the service, discovery service returns one of the available IPs Database like Query: our services request the database about the service address, and then uses it. It is very important to have service discovery linked to failure detection, so that discovery service returns only addresses of services that are running, and dynamically changes this list as services start or stop.
- Now, you already have a successful project under heavy load from your uses… and you need to scale it. Your microservices need to be stateless so that they can easily be started/stopped at any moment. When you start a new service instance, it must start receiving requests. If you are using HTTP, you need your service discovery solution to be able to get requests to the new instance. If you are using a message broker, the new service will be a new competing consumer for a given queue/topic and automatically receives all messages. With stateless services and load balancing, now, we can scale our services manually. Since we have virtualization or containers, we can programatically add new nodes to our infrastructure, our microservices can be added and automatically start adding more processing capabilities to the platform. In this moment, we would have the technical capabilities to dynamically scale. We need something that is able to start/stop microservices instances. That piece of code needs to know when to do it. How we decide about scaling? Monitoring, but what? CPU? Requests received by a microservice? Request time, as seen by client? we can have many of them, we would need to aggregate data… If you are using a message broker, there is a simple measure to check: QUEUE SIZE. Using it you can know when a microservice is receiving more requests that it is capable of processing.
- As a summary, we can see some of the advantages of microservices design: simple, loosely coupled (only talk through API) physical: by physical here I mean features that are a consecuence of services released as a set of independent computer programs in different processes. appropiate tool for the job, deliver independently, enabler for continuous delivery. This good parts are consequences of the microservices architecture.
- As a summary, we can see some of the advantages of microservices design: simple, loosely coupled (only talk through API) physical: by physical here I mean features that are a consecuence of services released as a set of independent computer programs in different processes. appropiate tool for the job, deliver independently, enabler for continuous delivery. This good parts are consequences of the microservices architecture.
- As a summary, we can see some of the advantages of microservices design: simple, loosely coupled (only talk through API) physical: by physical here I mean features that are a consecuence of services released as a set of independent computer programs in different processes. appropiate tool for the job, deliver independently, enabler for continuous delivery. This good parts are consequences of the microservices architecture.
- As a summary, we can see some of the advantages of microservices design: simple, loosely coupled (only talk through API) physical: by physical here I mean features that are a consecuence of services released as a set of independent computer programs in different processes. appropiate tool for the job, deliver independently, enabler for continuous delivery. This good parts are consequences of the microservices architecture.
- What is really wrong with monoliths? Bad Design and coupling. But you can do bad design also with microservices. It is true that it is much more easier to couple (code or database) when everything is in the same process and there are no clear APIs between modules. But it is our fault as developers, not that monoliths are flawed. On the other side, monoliths keeps many things much simpler (monitoring, CI, deployment, communications between modules, scaling, …). In simple projects, monoliths can help to deliver functionality faster… which is what it is expected from us. In the first slide we were talking about Amazon, Netflix, Twitter… all started with monoliths and they went very very far before having o split them. Not that all of our projects will be as successful as that companies. For that reason, we should be very careful when deciding what architectural style to use.