Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

#ATAGTR2020 Presentation - Microservices – Explored

11 views

Published on

Vikash Pandey delivered a session on "Microservices – Explored" at ATAGTR2020

ATAGTR2020 was the 5th Edition of Global Testing Retreat.

Vikash is an empathetic leader working with people & technology in the area Product Development, Consulting, Support and Operations for 20+ years

The video recording of the session is now available on the following link: https://youtu.be/dF5wx4w66s8

To know more about #ATAGTR2020, please visit: https://gtr.agiletestingalliance.org/

Published in: Technology
  • Be the first to comment

  • Be the first to like this

#ATAGTR2020 Presentation - Microservices – Explored

  1. 1. Microservices 101
  2. 2. Agenda What is microservices Why should microservices matter to us Trends supporting Microservices Advantages, concerns and mitigations Services and Libraries Important aspects of Microservices: Service discovery and registration Deployment Data Handling Migration strategies of monolith to microservices Let’s share varying perspectives
  3. 3. 43 Married, with a son (12) Pune, India. Indian citizen Strengths: Positivity, Maximizer, Developer, Arranger, Responsibility. • 20+ years in industry out of that 13+ years with FIS • Consulting, Delivery, Support • Result oriented, focused on solving problems • Technology enthusiast with strong interest in people and their success • Before FIS: • Fidelity Investments • Iflex Solutions • One Off Software Development • e-Enable Technologies • A blogger, a consistent learner, build and share my views • Advocate of DevOps, Cloud and Microservices • An Inbox thinker Who am I?
  4. 4. What is microservices Martin Fowler: an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource application programming interface (API). IBM describes it as a cloud-native approach to building applications from "loosely coupled and independently deployable smaller components, or services" that: • Have their own stack; • Use REST APIs and other forms of communication to connect to other services; and • Are sorted by business capability and separated into "need-to-know" chunks via bounded context. We can summarize it as: microservices are an app design architecture with a philosophy based on building independent components that all connect via API (HTTP, Thrift or REST) to reduce complexity, increase scalability, and allow applications to be distributed with more ease than traditional monolithic-style program architecture.
  5. 5. Why should microservices matter to us Few notable concerns Vanson Bourne on behalf of API management platform provider Kong, polled 200 senior IT leaders of organizations with more than 1,000 employees. • The survey also finds significant microservices challenges that remain are: • ensuring security (36%), • integration with legacy applications (32%), • the complexity of management (31%) and • updating API documentation (31%). • Despite these concerns, however, more than 80% of survey respondents who have adopted microservices report that their organization performs well against metrics for development efficiency, the ability to use new platforms, collaboration across teams and sharing of services across applications. • 89% of technology leaders agree that companies that are not able to effectively support microservices will be less able to compete in the future. • The primary reasons cited for adopting microservices are • improvements to security (56%), • increased development speed (55%), • increased speed of integrating new technologies (53%), • improved infrastructure flexibility (53%) and • improved collaboration across teams (46%) • Availability (75%), security (74%), performance (65%) and scalability (64%) are given highest importance. • Faster development speeds (95%), increased collaboration (94%) and reduced deployment risks (93%) as key desired outcomes for adopting any new technologies • The survey also notes 83% of organizations are relying on open-source software to become more agile. The most commonly used open-source technologies are databases (64%), containers (48%), API gateways (41%), infrastructure automation (40%), container orchestration (37%) and continuous integration/continuous delivery (CI/CD) tools (36%). The foundation, to fully utilize the capabilities of microservices, is to have a strong DevOps culture embedded in the team.
  6. 6. Trends supporting Microservices • In 2019, trends that were prominent and pervasive: • Test Automation, the result of test-driven development that requires developers to carry out tests throughout the Continuous Integration (CI) pipeline. • Incident Response, rise of Site Reliability Engineers is a response to the resiliency challenges of the systems. They were and are in charge of efficiency, performance, latency, availability, capacity planning, and emergency response. • Continuous Deployment, more developers were tooling around the deployments of microservices, which have cut down the cost associated with complexity. Organizations could keep on the trend of migration to microservice architectures. • In 2020, trends that are prominent and pervasive: • High microservices market growth, 22.5% in USA and overall, 27.4%. • Cloud adoption, organizations and their software delivery staff is moving away from locally hosted applications and shift into the cloud. • Observability tools, companies recognize how important observability is for distributed, microservices-based architectures. • Web services frameworks, developers will be able to use a framework for web services as microservices continue to evolve and offer development out-of-the-box capabilities and implementation of the service design patterns and code automatically. • Increased demand for frequent updates to the applications, In response to user demands for interactive, rich and dynamic experiences on various platforms, microservices can support the frequency demand. It also goes well with the need of scalability and agility to the applications having high availability, scalability, and easy-to-execute on the cloud platforms
  7. 7. Advantages, Concerns and Mitigations Few Advantages Challenges to look out for • Because the microservices function independently, each component can be built in whatever language the developer of that component prefers. • During initial stages it’s the complexity. The number of services and its deployment complexity. Until sorted delivery process, go slow. • Distribution cost, increased total latency across systems performing the business function. Carefully considering number of microservices.• Individual components can be updated on their own since their internal operation is inconsequential to the app as a whole. As long as they report back the correct data, the app will continue working. • Reduction of reliability, more moving parts in the system, the reliability suffers. Concepts like service mesh, observability and utilization of those tools could help. • Scaling can be done to each individual component, saving time and computing resources spent replicating entire applications to account for load on a single component. • Any service can call any service, there is no restriction at all. Hence a solid version strategy of service APIs is a recommended mitigation. Or think of Change Strategy. Versioning an API is like having your age in your name. Yes, I’m talking to you John32 and Emmanuel46. And then comes the fallacy of “nested” resources: If the resource John32 (/john32) has nested resource child (/john32/child), is the child resource of version 32 as well? Or is it a child when John was at version 32? What if the child is changing versions regardless of John32? - Zdenek Nemec In a survey it was found that point-to-point versioning, which is the strategy employed by most web API developers today, is 45% more costly with 4 different API versions than a Compatible Versioning strategy. While Compatible Versioning has a higher initial cost, over time, it provides huge cost savings. Change Strategy embraces Compatible Versioning strategy. • A component no longer meeting the need of its application can be replaced without affecting the app as a whole. • Applications can be decentralized between multiple cloud providers, servers, and other services both local and remote.
  8. 8. Services and Libraries Services Loosely Coupled Easily Upgradeable Libraries Tightly Coupled Complicated Jars Componentization via services : Teams must prefer distributing components as services rather than libraries
  9. 9. Microservices important aspects - Service discovery • When using client-side discovery, the client is responsible for determining the network locations of available service instances and load balancing requests across them. • Netflix Eureka is a service registry. It provides a REST API for managing service-instance registration and for querying available instances. Netflix Ribbon is an IPC client that works with Eureka to load balance requests across the available service instances. • relatively straightforward and, except for the service registry, there are no other moving parts. • since the client knows about the available services instances, it can make intelligent, application-specific load-balancing decisions such as using hashing consistently. • A significant drawback of this pattern is that it couples the client with the service registry. One must implement client-side service discovery logic for each programming language and framework used by your service clients. • When using server-side discovery The client makes a request to a service via a load balancer. The load balancer queries the service registry and routes each request to an available service instance. • The AWS Elastic Load Balancer (ELB) is an example of a server-side discovery router. • Some deployment environments such as Kubernetes and Marathon run a proxy on each host in the cluster. The proxy plays the role of a server-side discovery load balancer. • The service registry is a key part of service discovery. It is a database containing the network locations of service instances. Few examples are, Etcd, consul, and Apache Zookeeper …
  10. 10. Microservices important aspects - Service registration • When using the self-registration pattern, a service instance is responsible for registering and deregistering itself with the service registry. Netflix OSS Eureka client is an example of this pattern. • One benefit is that it is relatively simple and doesn’t require any other system components. • However, a major drawback is that it couples the service instances to the service registry. You must implement the registration code in each programming language and framework used by your services. • When using the third-party registration pattern, a system component known as the service registrar handles the registration. The service registrar tracks changes to the set of running instances by either polling the deployment environment or subscribing to events. the open source Registrator project and Netflix OSS Prana are examples of service registrars. • A major benefit is that services are decoupled from the service registry. You don’t need to implement service-registration logic for each programming language and framework used by your developers. • One drawback of this pattern is that unless it’s built into the deployment environment, it is yet another highly available system component that you need to set up and manage.
  11. 11. Microservices important aspects - Deployment • A microservices application consists of tens or even hundreds of services. Services are written in a variety of languages and frameworks. Each one is a mini-application with its own specific deployment, resource, scaling, and monitoring requirements. • Multiple service instance per host - We provision one or more physical or virtual hosts and run multiple service instances on each one. Each service instance runs at a well-known port on one or more hosts. These hosts require pet like treatments. • Each service instance to be a process or a process group and/or multiple service instances in the same process or process group. • Relatively efficient resource usage, deploying a service instance is relatively fast, starting a service is usually very fast. • There is little or no isolation of the service instances, unless each service instance is a separate process. While we can accurately monitor each service instance’s resource utilization, we cannot limit the resources each instance uses. A stronger dependency of operations on development as there will be technology specific deployments instructions to be passed on from development to operations, leading to increased risk of deployment errors. • Service instance per host- we run each service instance in isolation on its own host. Two flavors of this pattern, service instance per Virtual Machine and service instance per Container. We package each service as a virtual machine (VM) image such as an Amazon EC2 AMI. • Animator, packer.io are technologies that help build VM images. Boxfuse builds secure and lightweight VM images that are fast to build, boot quickly, and are more secure since they expose a limited attack surface. CloudNative has the Bakery, a SaaS offering for creating EC2 AMIs. We can configure our CI server to invoke the Bakery after the tests for your microservice pass. • Each service instance runs in complete isolation, can leverage mature cloud infrastructure with load balancing and autoscaling coming along by default, encapsulates our service’s implementation technology. • Less efficient resource utilization. Each service instance has the overhead of an entire VM, including the operating system, deploying a new version of a service is usually slow. VM images are typically slow to build due to their size. …
  12. 12. Microservices important aspects - Deployment • Service instance per container - each service instance runs in its own container. The processes that are running I a container have their own port namespace and root filesystem. We can limit a container’s memory and CPU resources. Examples of container technologies include Docker and Solaris Zones. • Our services need to be packaged as container images, it’s a filesystem image consisting of the application and dependent libraries. • Containers isolate our service instances from each other. We can easily monitor the resources consumed by each container. Also, like VMs, containers encapsulate the technology used to implement our services. The container management API also serves as the API for managing your services. Containers are lightweight than VMs. • Container is not as mature as the infrastructure for VMs, containers are not as secure as VMs since the containers share the kernel of the host OS with one another, we are responsible for the undifferentiated heavy lifting of administering the container images unless we use GCE and ECS. • The advancements are aiming to blur the distinction between containers and VMs. Boxfuse VMs are fast to build and start. The Clear Containers project aims to create lightweight VMs. • Serverless - AWS Lambda, an example of serverless, natively supports Java, Go, PowerShell, Node.js, C#, Python, and Ruby code, and provides a Runtime API which allows you to use any additional programming languages to author your functions. • The request-based pricing means that we only pay for the work that your services actually perform. Also, because we are not responsible for the IT infrastructure we can focus on developing your application. • Few significant limitations, not intended to be used to deploy long-running services, requests must complete within 300 seconds, s, must be written in one of the supported languages, services must be stateless, services must also start quickly.
  13. 13. Microservices important aspects - Data Handling • Data access becomes much more complex when we move to a microservices architecture. The data owned by each microservice is private to that microservice and can only be accessed via its API. • Different microservices often use different kinds of databases, SQL, NoSQL, Graph. • A partitioned, polyglot-persistent architecture for data storage has many benefits, including loosely coupled services and better performance and scalability. However, it does introduce some distributed data management challenges. • Two-Phase Commit is usually not a viable option in modern applications. The CAP theorem requires us to choose between availability and ACID-style consistency, and availability is usually the better choice. Moreover, many modern technologies, such as most NoSQL databases, do not support 2PC. • Another challenge is how to implement queries that retrieve data from multiple services. We may retrieve data using an application-side join, but that’s not the most optimal solution for various situations. • The solution is to use an event-driven architecture. In this architecture, a microservice publishes an event when something notable happens, such as when it updates a business entity. Other microservices subscribe to those events. When a microservice receives an event, it can update its own business entities, which might lead to more events being published. • It is important to note that transactions across microservices are not ACID transactions. They offer much weaker guarantees such as eventual consistency. This transaction model has been referred to as the BASE model (trading some consistency for availability for dramatic improvements in scalability). • It enables the implementation of transactions that span multiple services and provide eventual consistency. Another benefit is that it also enables an application to maintain materialized views. • The programming model is more complex than when using ACID transactions. Often we must implement compensating transactions to recover from application-level failures. Applications must deal with inconsistent data; the subscribers must detect and ignore duplicate events. …
  14. 14. Microservices important aspects - Data Handling • There are a few ways to achieve atomicity with event driven architecture as well- • The database as a message queue - publish events using a multi-step process involving only local transactions. This approach eliminates the need for 2PC by having the application use local transactions to update state and publish events. • Transaction log mining - The events to be published by a thread or process that mines the database’s transaction or commit log. The Transaction Log Miner thread or process reads the transaction log and publishes events to the Message Broker. • Event sourcing, rather than storing the current state of an entity, the application stores a sequence of state-changing events. The application reconstructs an entity’s current state by replaying the events. Whenever the state of a business entity changes, a new event is appended to the list of events. Since saving an event is a single operation, it is inherently atomic. • It solves one of the key problems in implementing an event-driven architecture and makes it possible to reliably publish events whenever state changes. As a result, it solves data consistency issues in a microservices architecture. • because it persists events rather than domain objects, it mostly avoids the object-relational impedance mismatch problem. • also provides a 100% reliable audit log of the changes made to a business entity and makes it possible to implement temporal queries that determine the state of an entity at any point in time. • our business logic consists of loosely coupled business entities that exchange events. This makes it a lot easier to migrate from a monolithic application to a microservices architecture. • We can use events to maintain materialized views that pre-join data owned by multiple microservices. The service that maintains the view subscribes to the relevant events and updates the view. This approach solves the challenge of how to implement queries that retrieve data from multiple services.
  15. 15. Migration strategies of monolith to microservices • We should stop the temptation to rewrite a monolith to microservices in a BIG BANG way. Martin Fowler reportedly commented that “the only thing a Big Bang rewrite guarantees is a Big Bang!”. • One application modernization strategy is the Strangler Application. One gradually builds a new application consisting of microservices and run it in conjunction with the monolithic application. Over time, the amount of functionality implemented by the monolithic application shrinks until either it disappears entirely, or it becomes just another microservice. • Here are a few strategies of doing this: • We should stop digging when we are in a hole. That means when we are implementing new functionality, we should not add more code to the monolith. Instead, the big idea with this strategy is to put that new code in a standalone microservice. • There are two additional components to this strategy, a router – that receives and redirects the legacy requests to monolith and new functionality requests to newly added microservices, and glue code - which integrates the service with the monolith. • A microservice can access the monolith’s data through either of the below listed strategy: • Invoke a remote API provided by the monolith • Access the monolith’s database directly • Maintain its own copy of the data, which is synchronized with the monolith’s database • The biggest benefit of stop digging strategy is It prevents the monolith from becoming even more unmanageable. The service can be developed, deployed, and scaled independently of the monolith. However, this approach does nothing to address the problems with the monolith. • To fix a monolith the solution is to break it, break it in layers, like front-end, back-end, DB Access etc. And another solution could be to start extracting services out of the monolith. A good approach is to start with a few modules that are easy to extract. This will give us experience with microservices in general and the extraction process in particular. After that we should extract those modules that will give us the greatest benefit.
  16. 16. Let’s hear

×