Jump to content

Microservices

From Wikipedia, the free encyclopedia

In software engineering, a microservice architecture is an architectural pattern that arranges an application as a collection of loosely coupled, fine-grained services, communicating through lightweight protocols. One of its goals is that teams can develop and deploy their services independently of others. This is achieved by the reduction of several dependencies in the code base, allowing developers to evolve their services with limited restrictions from users, and for additional complexity to be hidden from users.[1] As a consequence, organizations are able to develop software with fast growth and size, as well as use off-the-shelf services more easily. Communication requirements are reduced. These benefits come at a cost to maintaining the decoupling. So, microservice architecture can be a good choice only if the application is too complex to manage as a monolith.[2] Interfaces need to be designed carefully and treated as a public API. One technique that is used is having multiple interfaces on the same service, or multiple versions of the same service, so as to not disrupt existing users of the code.

A microservice is analogous to Bounded Context in Domain Driven Design. [3]

Introduction[edit]

There is no single definition for microservices. A consensus has evolved over time in the industry. Some of the defining characteristics that are frequently cited include:

A microservice is not a layer within a monolithic application (for example, the web controller or the backend-for-frontend).[10] Rather, it is a self-contained piece of business functionality with clear interfaces, and may, through its own internal components, implement a layered architecture. From a strategic perspective, microservice architecture essentially follows the Unix philosophy of "Do one thing and do it well".[11] Martin Fowler describes a microservices-based architecture as having the following properties:[4]

It is common for microservices architectures to be adopted for cloud-native applications, serverless computing, and applications using lightweight container deployment. According to Fowler, because of the large number (when compared to monolithic application implementations) of services, decentralized continuous delivery and DevOps with holistic service monitoring are necessary to effectively develop, maintain, and operate such applications.[15] A consequence of (and rationale for) following this approach is that the individual microservices can be individually scaled. In the monolithic approach, an application supporting three functions would have to be scaled in its entirety even if only one of these functions had a resource constraint.[16] With microservices, only the microservice supporting the function with resource constraints needs to be scaled out, thus providing resource and cost optimization benefits.[17]

History[edit]

There are numerous claims as to the origin of the term microservices. As early as 2005, Peter Rodgers introduced the term "Micro-Web-Services" during a presentation at the Web Services Edge conference. Against conventional thinking and at the height of the SOAP service-oriented architecture (SOA) hype curve he argued for "REST-services" and on slide #4 of the conference presentation, he discusses "Software components are Micro-Web-Services".[18] He goes on to say "Micro-Services are composed using Unix-like pipelines (the Web meets Unix = true loose-coupling). Services can call services (+multiple language run-times). Complex service assemblies are abstracted behind simple URI interfaces. Any service, at any granularity, can be exposed." He described how a well-designed microservices platform "applies the underlying architectural principles of the Web and REST services together with Unix-like scheduling and pipelines to provide radical flexibility and improved simplicity in service-oriented architectures.[18]

Rodgers' work originated in 1999 with the Dexter research project at Hewlett Packard Labs, whose aim was to make code less brittle and to make large-scale, complex software systems robust to change.[19] Ultimately this path of research led to the development of resource-oriented computing (ROC), a generalized computation abstraction in which REST is a special subset.

In 2005 Alistair Cockburn wrote about hexagonal architecture which is a software design pattern that is used along with the microservices. This pattern makes the design of the microservice possible since it isolates in layers the business logic from the auxiliary services needed in order to deploy and run the microservice completely independent from others.

A workshop of software architects held near Venice in May 2011 used the term "microservice" to describe what the participants saw as a common architectural style that many of them had been recently exploring.[20] In May 2012, the same group decided on "microservices" as the most appropriate name. James Lewis presented some of those ideas as a case study in March 2012 at 33rd Degree in Kraków in Microservices - Java, the Unix Way,[21] as did Fred George[22] about the same time. Adrian Cockcroft, former director for the Cloud Systems at Netflix,[23] described this approach as "fine-grained SOA", pioneered the style at web-scale, as did many of the others mentioned in this article - Joe Walnes, Dan North, Evan Bottcher, and Graham Tackley.[24]

Microservices is a specialization of an implementation approach for service-oriented architectures used to build flexible, independently deployable software systems.[7] The microservices approach is the first realisation of SOA that followed the introduction of DevOps and is becoming more popular for building continuously deployed systems.[25]

In February 2020, the Cloud Microservices Market Research Report predicted that the global microservice architecture market size will increase at a CAGR of 21.37% from 2019 to 2026 and reach $3.1 billion by 2026.[26]

Service granularity[edit]

A key step in defining a microservice architecture is figuring out how big an individual microservice has to be. There is no consensus or litmus test for this, as the right answer depends on the business and organizational context.[27] For instance, Amazon uses a service-oriented architecture where service often maps 1:1 with a team of 3 to 10 engineers.[28]

To find the right level of service granularity, architects have to continuously iterate their component designs with programmers. Architects need to take into account user requirements, responsibilities and architectural characteristics (aka non-functional requirements).[3]

Generally, the terminology goes as such: services that are dedicated to a single task, such as calling a particular backend system or making a particular type of calculation, are called atomic services. Similarly, services that call such atomic services in order to consolidate an output, are called composite services.

It is considered bad practice to make the service too small, as then the runtime overhead and the operational complexity can overwhelm the benefits of the approach. When things get too fine-grained, alternative approaches must be considered - such as packaging the function as a library, moving the function into other microservices.[7]

If domain-driven design is being employed in modeling the domain for which the system is being built, then a microservice could be as small as an aggregate or as large as a bounded Context.[29]

In the granularity of microservices discussion, there is a spectrum. On one end are the Anaemic Services, which do not have a large number of responsibilities, and on the other end are the Modular Monolith, which are large modules of a system.

Benefits[edit]

The benefit of decomposing an application into different smaller services are numerous:

  • Modularity: This makes the application easier to understand, develop, test, and become more resilient to architecture erosion.[8] This benefit is often argued in comparison to the complexity of monolithic architectures.[30]
  • Scalability: Since microservices are implemented and deployed independently of each other, i.e. they run within independent processes, they can be monitored and scaled independently.[31]
  • Integration of heterogeneous and legacy systems: microservices are considered a viable means for modernizing existing monolithic software application.[32][33] There are experience reports of several companies who have successfully replaced parts of their existing software with microservices or are in the process of doing so.[34] The process for software modernization of legacy applications is done using an incremental approach.[35]
  • Distributed development: it parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently.[36] It also allows the architecture of an individual service to emerge through continuous refactoring.[37] Microservice-based architectures facilitate continuous integration, continuous delivery and deployment.[38]

Criticism and concerns[edit]

The microservices approach is subject to criticism for a number of issues:

  • Services form information barriers.[39]
  • Inter-service calls over a network have a higher cost in terms of network latency and message processing time than in-process calls within a monolithic service process.[4]
  • Testing and deployment are more complicated.[40][41]
  • Moving responsibilities between services is more difficult.[8] It may involve communication between different teams, rewriting the functionality in another language or fitting it into a different infrastructure.[4] However, microservices can be deployed independently from the rest of the application, while teams working on monoliths need to synchronize to deploy together.[35]
  • Viewing the size of services as the primary structuring mechanism can lead to too many services when the alternative of internal modularization may lead to a simpler design.[42] This requires understanding the overall architecture of the applications and interdependencies between components.[43]
  • Two-phased commits are regarded as an anti-pattern in microservices-based architectures, resulting in a tighter coupling of all the participants within the transaction. However, the lack of this technology causes awkward dances which have to be implemented by all the transaction participants in order to maintain data consistency.[44]
  • Development and support of many services are more challenging if they are built with different tools and technologies - this is especially a problem if engineers move between projects frequently.[45]
  • The protocol typically used with microservices (HTTP) was designed for public-facing services, and as such is unsuitable for working internal microservices that often must be impeccably reliable.[46]
  • While not specific to microservices, the decomposition methodology often uses functional decomposition, which does not handle changes in the requirements while still adding the complexity of services.[46]
  • The very concept of microservice is misleading since there are only services. There is no sound definition of when a service starts or stops being a microservice.[46]
  • Data aggregation. In order to have a full view of a working system, it is required to extract data sets from the microservices repositories and aggregate them into a single schema. For example, to be able to create operational reports that are not possible using a single microservice repository.

Complexities[edit]

The architecture introduces additional complexity and new problems to deal with, such as latency, message format design,[47] backup/availability/consistency (BAC),[48] load balancing and fault tolerance.[41] All of these problems have to be addressed at scale. The complexity of a monolithic application does not disappear if it is re-implemented as a set of microservices. Some of the complexity gets translated into operational complexity.[49] Other places where the complexity manifests itself are increased network traffic and resulting in slower performance. Also, an application made up of any number of microservices has a larger number of interface points to access its respective ecosystem, which increases the architectural complexity.[50] Various organizing principles (such as hypermedia as the engine of application state (HATEOAS), interface and data model documentation captured via Swagger, etc.) have been applied to reduce the impact of such additional complexity.

Best practices[edit]

According O'Reilly, each microservice should have its own architectural characteristics (a.k.a non functional requirements), and architects should not to define uniform characteristics for the entire distributed system.[3]

Latency is often measured through "99th percentile" because median and average latencies can be misleading as they can miss outliers. [51][page needed][52]

Technologies[edit]

Computer microservices can be implemented in different programming languages and might use different infrastructures. Therefore, the most important technology choices are the way microservices communicate with each other (synchronous, asynchronous, UI integration) and the protocols used for the communication (RESTful HTTP, messaging, GraphQL ...). In a traditional system, most technology choices like the programming language impact the whole system. Therefore, the approach to choosing technologies is quite different.[53]

The Eclipse Foundation has published a specification for developing microservices, Eclipse MicroProfile.[54][55]

Service mesh[edit]

See also: Service mesh

In a service mesh, each service instance is paired with an instance of a reverse proxy server, called a service proxy, sidecar proxy, or sidecar. The service instance and sidecar proxy share a container, and the containers are managed by a container orchestration tool such as Kubernetes, Nomad, Docker Swarm, or DC/OS. The service proxies are responsible for communication with other service instances and can support capabilities such as service (instance) discovery, load balancing, authentication and authorization, secure communications, and others.

In a service mesh, the service instances and their sidecar proxies are said to make up the data plane, which includes not only data management but also request processing and response. The service mesh also includes a control plane for managing the interaction between services, mediated by their sidecar proxies.[citation needed]

A comparison of platforms[edit]

Implementing a microservice architecture is very difficult. There are many concerns (see table below) that any microservice architecture needs to address. Netflix developed a microservice framework to support their internal applications, and then open-sourced[56] many portions of that framework. Many of these tools have been popularized via the Spring Framework – they have been re-implemented as Spring-based tools under the umbrella of the Spring Cloud[57] project. The table below shows a comparison of an implementing feature from the Kubernetes ecosystem with an equivalent from the Spring Cloud world.[58] One noteworthy aspect of the Spring Cloud ecosystem is that they are all Java-based technologies, whereas Kubernetes is a polyglot runtime platform.

Microservices concern Spring Cloud & Netflix OSS Kubernetes
Configuration management:[59] configuration for a microservice application needs to be externalized from the code and be retrievable via a simple service call. Spring Config Server, Netflix Archaius both support a Git-repository—based location for configuration. Archaius supports data typing of configuration. Kubernetes ConfigMaps exposes the configuration stored in etcd via services. Kubernetes Secrets supports the service-based secure deployment and usage of sensitive configuration information (such as passwords, certificates, etc.).
Service discovery: maintain a list of service instances that are available for work within a microservice domain. Spring Cloud Eureka allows clients to register to it, maintains a heartbeat with registered clients, and maps service names to hostnames for clients that lookup services by service name. Kubernetes Services provide deployment-time registration of instances of services that are internally available within the cluster. Ingress is a mechanism whereby a service can be exposed to clients outside the cluster.
Load balancing: The key to scaling a distributed system is being able to run more than one instance of a component. Load has to be then distributed across those instances via a load balancer. Spring Cloud Ribbon provides the ability for service clients to load balance across instances of the service. Kubernetes Service provides the ability for the service to be load-balanced across service instances. This is not the equivalent of what Ribbon provides.
API gateway: The granularity of APIs provided by microservices is often different than what a service client needs. API Gateways implement facades and provide additional services like proxying, and protocol translation, and other management functions. Spring Cloud Zuul provides configuration-based API facades Kubernetes Service and Ingress resources, Istio, Ambassador are solutions that provide both north–south (traffic into and out of data center) as well as east–west (traffic across data centers or clouds or regions) API gateway functions. Zuul can also be implemented along with Kubernetes, providing configuration at individual service level.
Security concerns: Many security concerns are pushed to the API gateway implementation. With distributed microservice applications, it makes sense to not reinvent the security wheel and allow for policy definition and implementation in components that are shared by all services. Spring Cloud Security addresses many security concerns through Spring Cloud Zuul The Kubernetes ecosystem provides service meshes like Istio, which are capable of providing security through their API gateway mechanisms.
Centralized logging: It is important to have a centralized log gathering and analysis infrastructure to manage a plethora of services – many of which are operating in a distributed fashion. ELK Stack (Elasticsearch, Logstash, Kibana) EFK Stack (Elasticsearch, Fluentd, Kibana)
Centralized metrics: A centralized area where the health and performance of the individual services and overall system can be monitored is essential to proper operations. Spring Spectator & Atlas Heapster, Prometheus, & Grafana
Distributed tracing: Per-process logging and metric monitoring have their place, but neither can reconstruct the complex paths that transactions take as they propagate across a distributed system. Distributed tracing is an essential tool for a microservices platform. Spring Cloud Sleuth Hawkular, Jaeger
Resilience and fault tolerance: Distributed systems must be capable of auto-routing around failures, and be capable of routing requests to the service instance that will provide an optimum response. Spring Hystrix, Turbine, & Ribbon Health check, service meshes (example: Istio)[60]
Autoscaling and self-healing: Distributed systems respond to higher load by scaling horizontally: the platform must detect and auto-respond to such conditions. Furthermore, the system needs to detect failures and attempt auto-restarts without operator input. - Health check, self-healing, and auto-scaling
Packaging, deployment, and scheduling: Large-scale systems require robust package management, and deployment systems to manage rolling or blue-green deployments, and rollbacks if necessary. A scheduler helps determine which particular execution node a new set of services can be deployed to based on current conditions. Spring Boot, Apache Maven. The Spring Cloud system does not have a true scheduler. Docker, Rkt, Kubernetes Scheduler & Deployment, Helm[61]
Job management: scheduled computations disconnected from any individual user requests. Spring Batch Kubernetes Jobs and Scheduled Jobs
Singleton application: limit a specific service to run as the only instance of that service within the entire system. Spring Cloud Cluster Kubernetes Pods

See also[edit]

References[edit]

  1. ^ "Microservice architectures: more than the sum of their parts?". IONOS Digitalguide. 2 March 2020. Retrieved 2022-03-29.
  2. ^ Fowler, Martin (2002). Patterns of Enterprise Application Architecture. Addison-Wesley Professional. ISBN 978-0321127426.
  3. ^ Jump up to: a b c Fundamentals of Software Architecture: An Engineering Approach. O'Reilly Media. 2020. ISBN 978-1492043454.
  4. ^ Jump up to: a b c d Martin Fowler. "Microservices". Archived from the original on 14 February 2018.
  5. ^ Newman, Sam (2015-02-20). Building Microservices. O'Reilly Media. ISBN 978-1491950357.
  6. ^ Wolff, Eberhard (2016-10-12). Microservices: Flexible Software Architectures. Addison-Wesley. ISBN 978-0134602417.
  7. ^ Jump up to: a b c Pautasso, Cesare (2017). "Microservices in Practice, Part 1: Reality Check and Service Design". IEEE Software. 34 (1): 91–98. doi:10.1109/MS.2017.24. S2CID 5635705.
  8. ^ Jump up to: a b c d Chen, Lianping (2018). Microservices: Architecting for Continuous Delivery and DevOps. The IEEE International Conference on Software Architecture (ICSA 2018). IEEE.
  9. ^ Jump up to: a b Nadareishvili, I., Mitra, R., McLarty, M., Amundsen, M., Microservice Architecture: Aligning Principles, Practices, and Culture, O'Reilly 2016
  10. ^ "Backends For Frontends Pattern". Microsoft Azure Cloud Design Patterns. Microsoft.
  11. ^ Lucas Krause. Microservices: Patterns and Applications. ASIN B00VJ3NP4A.
  12. ^ Ford, N; Richards, M; Sadalage, P; Dehghani, Z. "Software Architecture: The Hard Parts". Thoughtworks. Retrieved 2023-01-20.
  13. ^ "CI/CD for microservices architectures", Azure Architecture Center, Microsoft. Retrieved 9 January 2018.
  14. ^ Josuttis, N. (2007). SOA in Practice. Sebastopol, CA, US: O'Reilly. ISBN 978-0-596-52955-0.
  15. ^ Martin Fowler (28 August 2014). "Microservice Prerequisites". Archived from the original on Oct 3, 2023.
  16. ^ Richardson, Chris (November 2018). Microservice Patterns. Manning Publications. 1.4.1 Scale cube and microservices. ISBN 9781617294549.
  17. ^ Mendonca, Nabor C.; Jamshidi, Pooyan; Garlan, David; Pahl, Claus (2019-10-16). "Developing Self-Adaptive Microservice Systems: Challenges and Directions". IEEE Software. 38 (2): 70–79. arXiv:1910.07660. doi:10.1109/MS.2019.2955937. S2CID 204744007.
  18. ^ Jump up to: a b Rodgers, Peter (Feb 15, 2005). "Service-Oriented Development on NetKernel- Patterns, Processes & Products to Reduce System Complexity". CloudComputingExpo. SYS-CON Media. Archived from the original on 20 May 2018. Retrieved 19 August 2015.
  19. ^ Russell, Perry; Rodgers, Peter; Sellman, Royston (2004). "Architecture and Design of an XML Application Platform". HP Technical Reports. p. 62. Retrieved 20 August 2015.
  20. ^ Dragoni, Nicola; Giallorenzo, Saverio; Lafuente, Alberto Lluch; Mazzara, Manuel; Montesi, Fabrizio; Mustafin, Ruslan; Safina, Larisa (2017). "Microservices: Yesterday, Today, and Tomorrow". Present and Ulterior Software Engineering. pp. 195–216. arXiv:1606.04036. doi:10.1007/978-3-319-67425-4_12. ISBN 978-3-319-67424-7. S2CID 14612986.
  21. ^ James Lewis. "Micro services - Java, the Unix Way".
  22. ^ Fred George (2013-03-20). "MicroService Architecture: A Personal Journey of Discovery".
  23. ^ Farrow, Rik (2012). "Netflix heads into the clouds" (PDF).
  24. ^ James Lewis and Martin Fowler. "Microservices".
  25. ^ "Continuous Deployment: Strategies". javacodegeeks.com. 10 December 2014. Retrieved 28 December 2016.
  26. ^ Research, Verified Market. "Cloud Microservices Market 2020 Trends, Market Share, Industry Size, Opportunities, Analysis and Forecast by 2026 – Instant Tech Market News". Retrieved 2020-02-18.
  27. ^ O. Zimmermann, Domain-Specific Service Decomposition with Microservice API Patterns, Microservices 2019, https://www.conf-micro.services/2019/slides//keynotes/Zimmerman.pdf
  28. ^ "Amazon SOA mandate". 13 October 2011.
  29. ^ Vaughn, Vernon (2016). Domain-Driven Design Distilled. Addison-Wesley Professional. ISBN 978-0-13-443442-1.
  30. ^ Yousif, Mazin (2016). "Microservices". IEEE Cloud Computing. 3 (5): 4–5. doi:10.1109/MCC.2016.101.
  31. ^ Dragoni, Nicola; Lanese, Ivan; Larsen, Stephan Thordal; Mazzara, Manuel; Mustafin, Ruslan; Safina, Larisa (2017). "Microservices: How to Make Your Application Scale" (PDF). Perspectives of System Informatics. Lecture Notes in Computer Science. Vol. 10742. pp. 95–104. arXiv:1702.07149. Bibcode:2017arXiv170207149D. doi:10.1007/978-3-319-74313-4_8. ISBN 978-3-319-74312-7. S2CID 1643730.
  32. ^ Newman, Sam (2015). Building Microservices. O'Reilly. ISBN 978-1491950357.
  33. ^ Wolff, Eberhard (2016). Microservices: Flexible Software Architecture. Addison Wesley. ISBN 978-0134602417.
  34. ^ Knoche, Holger; Hasselbring, Wilhelm (2019). "Drivers and Barriers for Microservice Adoption – A Survey among Professionals in Germany". Enterprise Modelling and Information Systems Architectures. 14: 1:1–35–1:1–35. doi:10.18417/emisa.14.1.
  35. ^ Jump up to: a b Taibi, Davide; Lenarduzzi, Valentina; Pahl, Claus; Janes, Andrea (2017). "Microservices in agile software development: a workshop-based study into issues, advantages, and disadvantages". Proceedings of the XP2017 Scientific Workshops. doi:10.1145/3120459.3120483. S2CID 28134110.
  36. ^ Richardson, Chris. "Microservice architecture pattern". microservices.io. Retrieved 2017-03-19.
  37. ^ Chen, Lianping; Ali Babar, Muhammad (2014). "Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development". Proceedings Working IEEE/IFIP Conference on Software Architecture 2014 WICSA 2014. The 11th Working IEEE/IFIP Conference on Software Architecture(WICSA 2014). IEEE. doi:10.1109/WICSA.2014.45.
  38. ^ Balalaie, Armin; Heydarnoori, Abbas; Jamshidi, Pooyan (May 2016). "Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture" (PDF). IEEE Software. 33 (3): 42–52. doi:10.1109/ms.2016.64. hdl:10044/1/40557. ISSN 0740-7459. S2CID 18802650.
  39. ^ Stenberg, Jan (11 August 2014). "Experiences from Failing with Microservices".
  40. ^ Calandra, Mariano (7 April 2021). "Why unit testing is not enough when it comes to microservices".
  41. ^ Jump up to: a b "Developing Microservices for PaaS with Spring and Cloud Foundry".
  42. ^ Tilkov, Stefan (17 November 2014). "How small should your microservice be?". Innoq. Retrieved 4 January 2017.
  43. ^ Lanza, Michele; Ducasse, Stéphane (2002). "Understanding Software Evolution using a Combination of Software Visualization and Software Metrics" (PDF). In Proceedings of LMO 2002 (Langages et Modèles à Objets): 135–149. Archived from the original (PDF) on Feb 27, 2021.
  44. ^ Richardson, Chris (November 2018). "Chapter 4. Managing transactions with sagas". Microservice Patterns. Manning Publications. ISBN 978-1-61729454-9.
  45. ^ Devoxx (Aug 30, 2017). "10 Tips for failing badly at Microservices by David Schmitz". YouTube. Archived from the original on Apr 22, 2021.
  46. ^ Jump up to: a b c Löwy, Juval (2019). Righting Software 1st ed. Addison-Wesley Professional. pp. 73–75. ISBN 978-0136524038.
  47. ^ Pautasso, Cesare (2017). "Microservices in Practice, Part 2: Service Integration and Sustainability". IEEE Software. 34 (2): 97–104. doi:10.1109/MS.2017.56. S2CID 30256045.
  48. ^ Pautasso, Cesare (2018). "Consistent Disaster Recovery for Microservices: the BAC Theorem". IEEE Cloud Computing. 5 (1): 49–59. doi:10.1109/MCC.2018.011791714. S2CID 4560021.
  49. ^ Fowler, Martin. "Microservice Trade-Offs".
  50. ^ "BRASS Building Resource Adaptive Software Systems". U.S. Government. DARPA. April 7, 2015. "Access to system components and the interfaces between clients and their applications, however, are mediated via a number of often unrelated mechanisms, including informally documented application programming interfaces (APIs), idiosyncratic foreign function interfaces, complex ill-understood model definitions, or ad hoc data formats. These mechanisms usually provide only partial and incomplete understanding of the semantics of the components themselves. In the presence of such complexity, it is not surprising that applications typically bake-in many assumptions about the expected behavior of the ecosystem they interact with".
  51. ^ Understanding Distributed Systems: What every developer should know about large distributed applications. 2021. ISBN 978-1838430207.
  52. ^ Bhargav, Nikhil (2024-03-18). "What's the P99 Latency?". baeldung.com. Retrieved 2024-06-08. The mean and median often mask outliers
  53. ^ Wolff, Eberhard (2018-04-15). Microservices - A Practical Guide. CreateSpace Independent Publishing Platform. ISBN 978-1717075901.
  54. ^ Swart, Stephanie (14 December 2016). "Eclipse MicroProfile". projects.eclipse.org.
  55. ^ "MicroProfile". MicroProfile. Retrieved 2021-04-11.
  56. ^ Netflix OSS, Git Hub
  57. ^ Cloud, Spring
  58. ^ "Spring Cloud for Microservices Compared to Kubernetes", Developers, Red hat, 2016-12-09
  59. ^ Somashekar, Gagan; Gandhi, Anshul (2021-04-26). "Towards Optimal Configuration of Microservices". Proceedings of the 1st Workshop on Machine Learning and Systems. EuroMLSys '21. Online, United Kingdom: Association for Computing Machinery. pp. 7–14. doi:10.1145/3437984.3458828.
  60. ^ Managing microservices with the Istio service mesh, Kubernetes, May 2017
  61. ^ The Kubernetes Package Manager, Helm

Further reading[edit]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Microservices&oldid=1229030420"