Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Building cloud-ready Microservices
Similar to Building cloud-ready Microservices (20)
Recently uploaded
Recently uploaded (20)
Building cloud-ready Microservices
- 1. Building Cloud Ready Microservices
- 2. Agenda Motivation What is Microservices architecture ? Demo What is Cloud Native approach?
- 3. About Your Instructor…. Senior Software Engineer && Team Lead Vered Flis veredf@codevalue.net https://www.linkedin.com/in/vered-flis/ @CodeValue Founder of Women In Clouds Israel
- 4. Introduction To stay competitive Digital disruption Fast-fish eats slow-fish world Consumer requirements evolve rapidly Agility is a key Innovation Is Eating the World
- 5. Statistics - Digital Innovation Benchmark report 84% of organizations have embraced micro-services based architectures to enable innovation 40% have challenges with securing, scaling and/or ensuring performance for their micro-services . 71% believe organizations will fail within six years if they don’t keep pace with innovation
- 6. Cloud Adoption Statistics 94% of enterprises already use a cloud service 66% of enterprises already have a cloud team or a cloud center . The public cloud service market is expected to reach $623.3 billion by 2023 worldwide 83% of enterprise workloads will be in the cloud by 2020
- 7. Companies Adoption of Microservices
- 8. Cloud Native Approach Isn’t exclusive to public environments Enables to bring new ideas to market faster and respond sooner to customer demands . Fully exploits the advantages of the cloud computing delivery model It is about How not Where applications are created and deployed
- 10. Monolithic Architecture Monolithic architecture is a traditional way to build an application has single executable or deployable binary with single build system which build entire application and/or dependency, has single code base with multiple modules, “ ”
- 11. Monolithic Architecture Single structure containing all it’s components in the same process/container Components of the app are Tightly Coupled Can be vertically scaled Altering one feature, will require to update the entire app at once
- 12. Monolith – pros Simple to develop Simple to deploy Simple to scale Simple to test
- 13. Monolith – cons Hard to maintain - when app becomes large and team grows Low reliability - Bug in any module can potentially bring down the entire process Long term commitment to a single technology stack (developer cemetery) Long compilation and unit testing time Redeploy the entire application on each update
- 14. Longer development cycles Fewer releases
- 16. Small is the New Big 1990 Monolith Tight Coupling 2000s SOA Looser Coupling 2010s Microservice sDecoupled
- 17. Microservices Architecture Architectural style that structures an application as a collection of services that are Highly maintainable and testable Loosely coupled and Highly cohesive Independently deployable Organized around business capabilities Owned by a small team with a single purpose “ ”
- 18. Microservice - pros Easy to develop and understand Cheap to re-implement Fast to deploy CI/CD is a first citizen Each service scaled independently when needed Private data ownership
- 19. Microservices - pros Microservice does one thing well !!! Hard boundaries between services No commitment to a single technology stack (developer heaven) Allows frequent software releases Onboarding of new developers becomes easier
- 20. How do MS communicate with each other Communicate with one another through APIs Synchronous communication – HTTP/HTTPS Asynchronous protocol - AMQP
- 22. Microservices - cons Communication between services is complex Integration points between services should be carefully planned Testing and debugging is more challenging Hard to monitor and collect logs (distributed tracing) Deployment challengers
- 23. Containers – What and Why Platform which allows to build, test, and deploy applications quickly Packages software into standardized units (containers) Includes everything the software needs to run Allows to quickly deploy and scale applications into any environment
- 24. DEMO
- 25. When To Start With Monolith Your team is at founding stage You’re building an unproven product or proof of concept You have no Microservices experience
- 26. When To Start With Microservices You Need Quick, Independent Service Delivery A Piece of Your Platform Needs to Be Extremely Efficient You Plan To Grow Your Team
- 27. Takeaways A monolith isn’t a dated architecture. In certain circumstances, a monolith is ideal Plan and understand the relevance of the architecture Estimate the cost of implementation Microservices are here to stay
- 28. Thank You
Editor's Notes
- https://marutitech.com/microservices-architecture-in-2019/ https://www.bcg.com/publications/2019/talking-about-microservices.aspx - readdddd
- https://medium.com/@odedia/microservices-are-for-humans-not-machines-721a6a56344f https://www.datastax.com/blog/2019/04/five-ways-microservices-are-changing-business https://allcloud.io/blog/how-moving-to-microservices-will-increase-your-business-agility/ Companies large and small are going through a digital transformation journey, as they try to compete in this age of digital disruption. It’s no longer big-fish-eats-small-fish. Businesses today have to compete aggressively in the market to retain their competitive edge. Consumer requirements –(Availability, Realaibility, מהירות )evolve at a rapid pace and businesses have to improve the scope and quality of their products and services on a continuous basis to retain their consumer base and generate profits. Productivity levels can be increased by improving in-house processes, therefore, businesses have to focus upon streamlining their workflows and adopting new processes and methods to stimulate ROI generation. To do this, organizations require process automation methods that can be easily developed, maintained, deployed and scaled as and when they grow.
- https://devops.com/survey-sees-massive-adoption-of-microservices/ https://www.prnewswire.com/news-releases/nearly-forty-percent-of-public-company-technology-leaders-believe-organizations-will-fail-within-three-years-if-they-dont-keep-pace-with-digital-innovation-300973246.html https://konghq.com/resources/digital-innovation-benchmark-2020/?utm_source=pressrelease&utm_medium=referral&utm_campaign=2020-innovation-report a survey of 200 senior technology decision makers in the U.S., including CIOs, CTOs, VPs of IT, IT directors/architects and software engineers/developers from organizations across a range of industries, with respondents evenly divided between publicly traded and privately held companies that had 1,000 or more employees.
- https://tanzu.vmware.com/cloud-native
- https://divante.com/blog/10-companies-that-implemented-the-microservice-architecture-and-paved-the-way-for-others/
- https://tanzu.vmware.com/cloud-native
- https://tanzu.vmware.com/cloud-native Organizations require a platform for building and operating cloud native applications and services that automates and integrates the concepts of DevOps, continuous delivery, microservices, and containers: DevOps is the collaboration between software developers and IT operations with the goal of constantly delivering high-quality software that solves customer challenges. It has the potential to create a culture and an environment where building, testing and releasing software happens rapidly, frequently, and more consistently. Continuous Delivery, enabled by Agile product development practices, is about shipping small batches of software to production constantly, through automation. Continuous delivery makes the act of releasing dull and reliable, so organizations can deliver frequently, at less risk, and get feedback faster from end users. Microservices is an architectural approach to developing an application as a collection of small services; each service implements business capabilities, runs in its own process and communicates via HTTP APIs or messaging. Each microservice can be deployed, upgraded, scaled, and restarted independent of other services in the application, typically as part of an automated system, enabling frequent updates to live applications without impacting end customers. Containers offer both efficiency and speed compared with standard virtual machines (VMs). Using operating system (OS)-level virtualization, a single OS instance is dynamically divided among one or more isolated containers, each with a unique writable file system and resource quota. The low overhead of creating and destroying containers combined with the high packing density in a single VM makes containers an ideal compute vehicle for deploying individual microservices.
- https://medium.com/koderlabs/introduction-to-monolithic-architecture-and-microservices-architecture-b211a5955c63 The word monolith means “one massive stone” Many startups begin with a monolith, because its very structure lends itself well to small teams and offers other advantages like less operational overhead. Also, monoliths often just have one massive code base. Server side application logic, front end client side logic, background jobs, etc, are all defined in the same code base. This means that if developers want to make any changes or updates, they need to build and deploy the entire stack all at once. A monolith isn’t a dated architecture that we need to leave in the past. In certain circumstances, a monolith is ideal. I spoke to Steven Czerwinski, Head of Engineering at Scaylr and former Google employee, to better understand this. “Even though we had had these positive experiences of using microservices at Google, we [at Scaylr] went [for a monolith] route because having one monolithic server means less work for us as two engineers,” he explained. This was back in the early beginnings of Scalyr. In other words, because his team was small, a unified application was more manageable in comparison to splitting everything up into microservices.
- Authorization — responsible for authorizing a user Presentation — responsible for handling HTTP requests and responding with either HTML or JSON/XML (for web services APIs). Business logic — the application’s business logic. Database layer — data access objects responsible for accessing the database. Application integration — integration with other services (e.g. via messaging or REST API). Or integration with any other Data sources. Notification module — responsible for sending email notifications whenever needed. Many startups begin with a monolith, because its very structure lends itself well to small teams and offers other advantages like less operational overhead. Also, monoliths often just have one massive code base. Server side application logic, front end client side logic, background jobs, etc, are all defined in the same code base. This means that if developers want to make any changes or updates, they need to build and deploy the entire stack all at once. A monolith isn’t a dated architecture that we need to leave in the past. In certain circumstances, a monolith is ideal. I spoke to Steven Czerwinski, Head of Engineering at Scaylr and former Google employee, to better understand this. “Even though we had had these positive experiences of using microservices at Google, we [at Scaylr] went [for a monolith] route because having one monolithic server means less work for us as two engineers,” he explained. This was back in the early beginnings of Scalyr. In other words, because his team was small, a unified application was more manageable in comparison to splitting everything up into microservices.
- Simple to develop- less operational overhead, most of todays IDEs support monolithic app development Simple to deploy – less operational overhead, just copy the app to designated runtime. Simple to scale as a whole –just run additional copies of the same app behind load balancer. Relatively easy to monitor and collect logs. Simple to test. For example, you can implement end-to-end testing by simply launching the application and testing the UI with Selenium.
- Maintenance — If Application is too large and complex to understand entirely, it is challenging to make changes fast and correctly. The size of the application can slow down the start-up time. You must redeploy the entire application on each update. Monolithic applications can also be challenging to scale when different modules have conflicting resource requirements. Reliability — Bug in any module (e.g. memory leak) can potentially bring down the entire process. Moreover, since all instances of the application are identical, that bug impact the availability of the entire application Regardless of how easy the initial stages may seem, Monolithic applications have difficulty to adopting new and advance technologies. Since changes in languages or frameworks affect an entire application, it requires efforts to thoroughly work with the app details, hence it is costly considering both time and efforts. Only scales one dimension -we cannot scale each component independently.
- Maintenance — If Application is too large and complex to understand entirely, it is challenging to make changes fast and correctly. The size of the application can slow down the start-up time. You must redeploy the entire application on each update. Monolithic applications can also be challenging to scale when different modules have conflicting resource requirements. Reliability — Bug in any module (e.g. memory leak) can potentially bring down the entire process. Moreover, since all instances of the application are identical, that bug impact the availability of the entire application Regardless of how easy the initial stages may seem, Monolithic applications have difficulty to adopting new and advance technologies. Since changes in languages or frameworks affect an entire application, it requires efforts to thoroughly work with the app details, hence it is costly considering both time and efforts.
- Chris Richardson’s definition of microservices at microservices.io
- Major Differences Between Microservices and SOA in Detail: Service Granularity: Service components within a microservices architecture are generally single-purpose services that do one thing really, really well. With SOA, service components can range in size anywhere from small application services to very large enterprise services. In fact, it is common to have a service component within SOA represented by a large product or even a subsystem. Component Sharing: Component sharing is one of the core tenets of SOA. As a matter of fact, component sharing is what enterprise services are all about. SOA enhances component sharing, whereas MSA tries to minimize on sharing through “bounded context.” A bounded context refers to the coupling of a component and its data as a single unit with minimal dependencies. As SOA relies on multiple services to fulfill a business request, systems built on SOA are likely to be slower than MSA. Middleware vs API layer: The microservices architecture pattern typically has what is known as an API layer, whereas SOA has a messaging middleware component. The messaging middleware in SOA offers a host of additional capabilities not found in MSA, including mediation and routing, message enhancement, message, and protocol transformation. MSA has an API layer between services and service consumers. Remote services: SOA architectures rely on messaging (AMQP, MSMQ) and SOAP as primary remote access protocols. Most MSAs rely on two protocols – REST and simple messaging (JMS, MSMQ), and the protocol found in MSA is usually homogeneous. Heterogeneous interoperability: SOA promotes the propagation of multiple heterogeneous protocols through its messaging middleware component. MSA attempts to simplify the architecture pattern by reducing the number of choices for integration. If you would like to integrate several systems using different protocols in a heterogeneous environment, you need to consider SOA. If all your services could be exposed and accessed through the same remote access protocol, then MSA is a better option.
- Chris Richardson’s definition of microservices at microservices.io Amazon CEO Jeff Bezos -It's simple. The more people you pack into the meeting, the less productive the meeting will likely be. The solution? Never have a meeting where two pizzas couldn't feed the entire group.
- app will run different services as independent units, each with its own runtime, codebase, processing thread
- app will run different services as independent units, each with its own runtime, codebase, processing thread Even if a Microsevice goes down, it won’t take everything else down with it
- app will run different services as independent units, each with its own runtime, codebase, processing thread APIs — a set of predefined commands, functions, and protocols. Developers can take advantage of API libraries, and in most cases they’re given permission to add new ones and share them with the community. APIs are the common language used to enable communication between microservices and other forms of architecture. There are many new technologies taking advantage of the rise in microservice culture — Docker, a “software container”, is perhaps the most relevant example. With Docker, and similar platforms like Nomad and Kumbemetes, we can replace traditional web server models with smaller and much more adaptable virtualised software containers. Thanks to easy-to-configure “middleware” software solutions, we can ensure the flow of information between systems is accurate and reduce the risk of losing track of any data. Let’s take a look at some of the pros and cons of microservices. This should help us explain how we, at Good Rebels, determine which form of architecture is right for a team or organisation.
- Communication between services is complex: Since everything is now an independent service, you have to carefully handle requests traveling between your modules. In one such scenario, developers may be forced to write extra code to avoid disruption. Over time, complications will arise when remote calls experience latency. More services equals more resources: Multiple databases and transaction management can be painful. Global testing is difficult: Testing a microservices-based application can be cumbersome. In a monolithic approach, we would just need to launch our WAR on an application server and ensure its connectivity with the underlying database. With microservices, each dependent service needs to be confirmed before testing can occur. Debugging problems can be harder: Each service has its own set of logs to go through. Log, logs, and more logs. Deployment challengers: The product may need coordination among multiple services, which may not be as straightforward as deploying a WAR in a container.
- Though Docker still made up 83 percent of containers in 2018, that number is down from 99 percent in 2017. Other container runtime environments including CoreOS rkt, Mesos, lxc Windows Server Containers. Linux VServer. Hyper-V Containers. Unikernels. Java containers. everything the software needs to run including libraries, system tools, code, and runtime
- Maintenance — If Application is too large and complex to understand entirely, it is challenging to make changes fast and correctly. The size of the application can slow down the start-up time. You must redeploy the entire application on each update. Monolithic applications can also be challenging to scale when different modules have conflicting resource requirements. Reliability — Bug in any module (e.g. memory leak) can potentially bring down the entire process. Moreover, since all instances of the application are identical, that bug impact the availability of the entire application Regardless of how easy the initial stages may seem, Monolithic applications have difficulty to adopting new and advance technologies. Since changes in languages or frameworks affect an entire application, it requires efforts to thoroughly work with the app details, hence it is costly considering both time and efforts.
- https://www.thesunflowerlab.com/blog/microservice-architecture-benefits-business-value/ Your Team Is At Founding Stage: Your team is small, between 2–5 members, and is thus unable to tackle a broader and high-overhead microservices architecture. You’re Building An Unproven Product or Proof of Concept: Are you building an unproven product in the market? If it’s a new idea, it’s likely going to pivot and evolve over time, so a monolith is ideal to allow for rapid product iteration. Same applies to a proof of concept where your goal is just to learn as much as possible as quickly as possible, even if you end up throwing it away. You Have No Microservices Experience: If your team has no prior experience with microservices, unless you can justify taking the risk of learning “on the fly” at such an early stage, it’s likely another sign you should stick to a monolith to start.
- https://www.thesunflowerlab.com/blog/microser You Need Quick, Independent Service Delivery: Microservices allow for fast, independent delivery of individual parts within a larger, integrated system. Note, depending on your team size, it can take time to see service delivery gains versus starting with monolith. A Piece of Your Platform Needs to Be Extremely Efficient: If your business is doing intensive processing of petabytes of log volume, you’ll likely want to build that service out in a very efficient language. You Plan To Grow Your Team: Starting with microservices gets your team used to developing in separate small services from the beginning, and having teams separated by service boundaries makes it much easier to scale up your team when you need to without introducing exponential complexity. vice-architecture-benefits-business-value/