The Monolith Strikes Back: Why Istio Migrated From Microservices to a Monolithic Architecture
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Editor: Cesare Pautasso
University of Lugano
INSIGHTS c.pautasso@ ieee.org
Editor: Olaf Zimmermann
University of Applied Sciences
of Eastern Switzerla nd, Rapperswil
olaf.zimmermann@ost.ch
The Monolith Strikes
Back: Why Istio Migrated
From Microservices to a
Monolithic Architecture
Nabor C. Mendonça, Craig Box, Costin Manolache, and Louis Ryan
From the Editors
To break or not to break the monolith? This question of modularity is often answered
positively by microservice architects. In this issue’s “Insights” department, authors ar-
gue why the latest version of the popular Istio middleware—which provides the fabric
of many contemporary microservice architectures—has not been released as a set
of independently deployable components, but as a single unit that is tested, deployed,
and scaled as a whole. We learn that modularity affects the entire software lifecycle:
it is not only a development and maintenance concern but also a deployment-time
decision. The operator experience matters, just like user experience and developer
experience.— Cesare Pautasso and Olaf Zimmermann
MICROSERVICES HAVE BECOME which server-side applications are con- single unit that is tested, deployed, and
an essential architectural enabler in structed by combining many single- scaled as a whole.
cloud-based software development and purpose, low-footprint distributed Despite their benefits, the adoption
delivery.1 Many organizations, from services.3 This significantly impacts of microservices poses several techni-
large tech companies (e.g., Google, the application’s agility because each cal and organizational challenges, for
Amazon, Netflix) to small start-ups, microservice becomes an independent example, high operational complexity,
have adopted microservices as a best unit of development, deployment, ver- increased technological diversity, and
practice.2 This has served them well in sioning, scaling, and management.1 The the need for better coordination among
some cases and, as you will see here, other touted benefits of microservices teams.1,3,4 Early evidence on the practi-
not so well in others. include reduced testing effort, better cal gains and pains of microservices have
Briefly, microservices constitute a functional composition, environmen- started to emerge in academic publica-
service-oriented architectural style in tal isolation, and development team tions5–7 and industry forums.8 However,
autonomy.4 The opposite is a more there are still relatively few industrial re-
Digital Object Identifier 10.1109/MS.2021.3080335
monolithic architecture, where several ports on microservice projects in which
Date of current version: 20 August 2021 discrete functions are composed into a the pains are assessed to outweigh the
This work is licensed under a Creative Commons Attribution 4.0
License. For more information, see https://creativecommons.org/ SEPTEMBER/OCTOBER 2021 | IEEE SOFTWARE 17
licenses/by/4.0/deed.ast.
INSIGHTS
gains.9,10 In these situations, project de- deployed in Kubernetes, an open source application-specific metrics (e.g., latency
velopers may have to face the nontrivial container orchestration platform that and error rate per service).
decision of abandoning microservices in has become the de facto standard for Istio’s original control plane ar-
favor of a monolithic architecture. managing containerized applications.13 chitecture was composed of five in-
This article reports on the de- Istio is logically split into a data plane dependently deployable microservices
sign decisions, tradeoffs, and lessons and a control plane from an architec- [see Figure 1(a)]:
learned from one of those projects— tural perspective, similar to other ser-
the Istio open source service mesh.11 vice mesh solutions.14 The data plane • Pilot—the core data plane con-
Istio adopted a microservice archi- is composed of a set of Envoy proxies15 figuration service, which provides
tecture in its control plane early on. deployed as application service sidecars. service discovery for the Envoy
However, less than three years after These proxies mediate and control all proxies, traffic management
Istio was first released, the con- network communication between ap- capabilities for intelligent routing
trol plane microservices were con- plication containers. They also collect (e.g., A/B tests, canary rollouts,
solidated into a monolith. You can and report telemetry on all mesh traf- etc.), and resiliency (timeouts,
find more information on Istio’s fic. The control plane, in turn, manages retries, circuit breakers, etc.)
microservices-to-monolith journey in and configures the data plane proxies • Citadel—service respon-
the project’s online blog.12 to monitor and route application traffic sible for enforcing strong
according to user-provided traffic man- service-to-service and end-user
Istio agement rules. A monitoring back end authentication with built-in iden-
Istio was released to the public in 2017 running systems such as Prometheus,16 tity and credential management
as a collaboration among Google, IBM, a metrics server, and Jaeger,17 a distrib- • Galley—service responsible for
and Lyft. The system provides a uni- uted tracer, is also typically deployed configuration validation, ingestion,
form way to connect, secure, manage, alongside the control plane to col- processing, and distribution of
and monitor cloud-native applications lect and store a variety of mesh- and configuration to the other services
FIGURE 1. The architectural evolution of Istio’s control plane: (a) microservices and (b) monolith.
18 I E E E S O F T WA R E | W W W. C O M P U T E R . O R G / S O F T W A R E | @ I E E E S O F T WA R E
INSIGHTS
• Injector—service responsible them into a single binary: istiod [see time of writing, computer resource costs
for auto-injecting the data plane Figure 1(b)]. This unified service com- in the Istio control plane are dominated
proxies in the application con- bines the use cases of Pilot, Citadel, by a single feature: serving the Envoy
tainers and setting up bootstrap Galley, and Injector. The Mixer com- dynamic resource discovery (i.e., xDS)
• Mixer—service responsible for en- ponent was removed in a concurrent APIs that program the data plane. Every
forcing access control and usage project. The Envoy proxies now di- other feature has a marginal cost. This
policies across the service mesh; it rectly enforce policy and report telem- means there is very little value to hav-
also collects telemetry data from etry to the monitoring back end, which ing those features in separately scalable
the Envoy proxies and other ser- had previously been performed using microservices. Also, full security isola-
vices and reports this data to the the Mixer as a central intermediary. tion is not attainable in the control plane
monitoring back end. The motivation for this change was as well. This is because multiple control
similar to that of istiod in that a design plane services hold nearly equivalent
Microservice Burdens pattern identified as necessary at mas- roles in securing behavior of the proxy
The Istio team thought microservices sive operational scale was not justified and are installed by default into the same
were the right architectural approach against the maintenance and perfor- Kubernetes namespace. Thus, exploiting
from the very beginning, as many of mance overheads for typical users. any of these services would cause near
the authors had developed and oper- Compared to Istio’s previous mi equal damage. Therefore, moving the
ated a similar system within Google croservice architecture, this new Istio control plane to a monolithic archi-
and ported what they knew. Thus, they monolithic control plane offers several tecture turned out to be the right archi-
initially built the control plane as a set benefits. Here are some examples. First, tectural decision.
of microservices, like a modern, cloud- installation is simplified, as fewer Ku- We should note that internally Istio
native application. As Istio adoption bernetes deployments and associated still maintains the logical separation be-
increased and the team got feedback configurations are required. Second, tween some of its original control plane
from customers, they realized that configuration becomes more straight- components and that each capability is
many of the benefits typically associ- forward, as many of the configuration exposed as a discrete API. This still en-
ated with microservices, that is, inde- options that Istio had before were ables functions to be swapped and com-
pendent rollout, independent scale, and ways to orchestrate the control plane bined with other implementations. This
security isolation, did not apply to the services and therefore are no longer feature can be particularly useful in
Istio control plane. In most Istio instal- needed. Third, debugging becomes some advanced use cases, such as in
lations, all control plane components less of a burden, as having fewer ser- multicluster deployments, where istiod
are installed and operated by a single vices means less cross-service envi- can be deployed as a single-purpose ser-
team or individual. This means that ronmental debugging. Scalability is vice such as “injection,” “certification
most Istio components are not deliv- also simplified, as there is now only provider,” or “validation.” This design
ered and managed independently from one service to scale. Finally, the time decision maintains many of the ben-
one another. Consequently, Istio opera- to start, upgrade, and remove Istio efits of microservices to more seasoned
tors were paying the price of the greater goes down, as these no longer require Istio operators without the downsides
operational complexity inherent to a a complicated dance of version de- to those only interested in Istio’s most
microservice architecture without ben- pendencies and start-up orders. common use cases.
efiting from it. While the teams oper-
ating Istio may have the skills to offset Monolith Tradeoffs Lessons Learned
these challenges, they did not perceive Generally, when a team adopts microser- According to Sam Newman, author of
any value in performing that work. vices and their inherent complexity, they a recent book on microservice migra-
look for improvements in other areas tion patterns,18 developers should con-
From Microservices to justify the tradeoffs. After looking at template these three questions before
to a Monolith the Istio control plane through that lens, adopting a microservice architecture:
Once the team established that many the team concluded that the value of mi- What are you hoping to achieve? Have
of the expected benefits of microser- croservices was not greater than the cost you considered alternatives to using
vices did not apply to the Istio con- of having to orchestrate them during microservices? How will you know
trol plane, they decided to consolidate setup and operation. For instance, at the if the transition is working? Here we
SEPTEMBER/OCTOBER 2021 | I E E E S O F T WA R E 19
INSIGHTS
report on the main lessons learned Had the Team Considered facilitated when done in an open and
from the Istio team’s decision to con- Alternatives to Using constructive “error culture.”
solidate their microservices from the Microservices?
perspectives of these three questions. In retrospect, the team admits that How Did the Team Know
We also discuss whether this decision they favored microservices because Microservices Were Not
aligns with industry best practices. they confused their operational ex- Working?
perience for that of the end-user. At first, the Istio team did not pay
What Was the Team For Istio, they are not the operator. much attention to the burden of
Hoping to Achieve With Thus, the need for the control plane managing Istio’s control plane as
Microservices? services to communicate securely independently deployable microser-
Initially, the Istio team expected to and be observable provided oppor- vices. However, after the team
benefit from microservices’ well- tunities for Istio to “eat its own dog started receiving feedback from
known advantages, such as indepen- food.” To put it another way, be- other Istio users, they soon real-
dent rollout and independent scale. cause Istio was targeted explicitly ized that microservices were not
However, as they regularly talked at securing and observing individ- as beneficial as they initially had
to customers and teams running Is- ual microservices, the team thought thought. The main reason was that
tio in the real world, they were told implementing the Istio control plane all control plane services were be-
that none of these were the case for as secure and observable microser- ing deployed and used together and
the Istio control plane. The first les- vices was a natural choice. As we shared the same administrative and
son learned then is that good teams have seen, this wasn’t necessarily the security domains. Thus, moving the
should look back upon their design case. In summary, the team believes Istio control plane to a monolithic
choices and, with the benefit of hind- honesty and courage are required architecture was a welcome deci-
sight, revisit them.19 to undo a previous design, which is sion, as it greatly reduced Istio’s
operational complexity. While this
decision may seem like a significant
Table 1. Sam Newman’s recommendations on when not change, the Istio team is confident
to use microservices and whether they apply to Istio. that it has paid off and verifiably
made the lives of Istio users better.
Situation Why Microservices Are Bad Does It Apply to Istio? Thus, the team thinks this change
shows a willingness to change based
Unclear Getting service boundaries wrong can In part. From the perspective of fault
domain be expensive. and security isolation, it can be argued on user feedback and a continued
that splitting the Istio control plane into focus on simplification for all users.
multiple independent services was an
unnecessary decision. How Well Does the Decision to
Start-ups A start-up needs to focus all its In part. While Istio was initially designed Consolidate the Control Plane
attention on finding the right fit for its by mature organizations, it was run like Microservices Align With
product. Microservices primarily solve a start-up and did indeed need to focus Industry Best Practices?
the sorts of problems start-ups have on finding the right fit. As it turned out,
once they’ve found that fit with their microservices were solving a problem
To answer this question, we again re-
customer base. Istio didn’t actually have. sort to Sam Newman’s microservice
recommendations, in particular, to his
Customer- Microservices push a lot of complexity Yes. Negative user feedback on the
list of four situations in which microser-
installed and into the operational domain. Coping complexity of deploying and managing
managed with this complexity isn’t something Istio was the main reason for the team’s vices might be a bad idea.16 Table 1
software you can typically expect of your end decision to consolidate the control plane briefly describes those four situations
customers. microservices into a single binary. and whether they apply to Istio. As
Not having Do not adopt microservices if you In part. Although the Istio team had a you can see, all of them apply to Istio,
a good don’t have a clear idea of what exactly clear view of the benefits and cost of either partially or in full. Notably, us-
reason! it is that you’re trying to achieve. microservices, they didn’t realize right ing microservices in customer-installed
from the start that, in their case, the and -managed software was the clear
costs would outweigh the benefits.
reason that microservices were a bad
20 I E E E S O F T WA R E | W W W. C O M P U T E R . O R G / S O F T W A R E | @ I E E E S O F T WA R E
INSIGHTS
idea in Istio’s case. The others are par- that microservices are not, and never architectural term.” martinFowler,
tial and might not be very convincing, will be, the right solution in all cases. Mar. 2014. https://martinfowler.com/
but this one has clear guidance rel- Microservices are a tool in a toolbox, articles/microservices.html (accessed
evant to readers: if you ship customer- and they work best when reflected in May 28, 2021).
installed software, be wary of shipping the organizational reality. 4. O. Zimmermann, “Microservices
a bunch of microservices. One final tenets: Agile approach to service
lesson learned then is that although Acknowledgment development and deployment,” Com-
the Istio team was aware of Sam New- Nabor C. Mendonça was partly sup- put. Sci.—Res. Develop., vol. 32,
man’s microservice recommendations, ported by Brazil’s National Council for nos. 3–4, pp. 301–310, 2017. doi:
they didn’t give appropriate weight to Scientific and Technological Develop- 10.1007/s00450-016-0337-0.
the guidance around operations. This ment under grants 424160/2018-8 5. J. Soldani, D. A. Tamburri, and
shows the importance of sharing real- and 311344/2020-8. W. J. Van Den Heuvel, “The pains
world microservice experiences with a and gains of microservices: A sys-
broader audience, especially those that References tematic grey literature review,” J.
did not turn out as well as expected. 1. P. Jamshidi, C. Pahl, N. C. Men- Syst. Softw., vol. 146, pp. 215–
donça, J. Lewis, and S. Tilkov, 223, Dec. 2018. doi: 10.1016/j.
A
“Microservices: The journey so jss.2018.09.082.
s microservices become in- far and challenges ahead,” IEEE 6. H. Zhang, S. Li, Z. Jia, C. Zhong and
creasingly popular, they Softw., vol. 35, no. 3, pp. 24–35, C. Zhang, “Microservice architec-
are more likely to be used May/June 2018. doi: 10.1109/ ture in reality: An industrial inquiry,”
in situations where the costs far out- MS.2018.2141039. Proc. IEEE Int. Conf. Softw. Archi-
weigh the benefits. Istio’s recent deci- 2. C. Pautasso, O. Zimmermann, M. tecture (ICSA 19), 2019, pp. 51–60.
sion to migrate its control plane from Amundsen, J. Lewis, and N. Josuttis, doi: 10.1109/ICSA.2019.00014.
microservices to a monolithic architec- “Microservices in practice, part 1: 7. H. Knoche and W. Hasselbring,
ture is a real-world example of some Reality check and service design,” “Drivers and barriers for microser-
of these situations. While the Istio IEEE Softw., vol. 34, no. 1, pp. 91– vice adoption—A survey among pro-
team recognizes that microservices 98, Jan./Feb. 2017. doi: 10.1109/ fessionals in Germany,” Enterprise
can work well in some systems and use MS.2017.24. Model. Inform. Syst. Architectures,
cases, their unmet expectations with 3. J. Lewis and M. Fowler. “Microser- vol. 14, no. 1, pp. 1–35, 2019. doi:
microservices are a timely reminder vices: A definition of this new 10.18417/emisa.14.1.
ABOUT THE AUTHORS
NABOR C. MENDONÇA is a full professor COSTIN MANOLACHE is a software
at the University of Fortaleza, Fortaleza, Ceará, engineer at Google. Contact him at costin@
CEP 60811-905, Brazil. Contact him at nabor@ google.com.
unifor.br.
CRAIG BOX is a developer advocate at LOUIS RYAN is a principal engineer at
Google. Contact him at craigbox@google.com. Google. Contact him at lryan@google.com.
SEPTEMBER/OCTOBER 2021 | I E E E S O F T WA R E 21
INSIGHTS
8. “Panel: Microservices—Are they still istio.io/ (accessed May 28, 16. “Prometheus—From metrics to
worth it?” InfoQ, Apr. 2020. https:// 2021). insight.” Prometheus.io. https://
www.infoq.com/presentations/ 12. C. Box. “Introducing istiod: Simplify- prometheus.io/ (accessed May 28,
microservices-panel-value/ (accessed ing the control plane.” Istio.io, Mar. 2021).
May 28, 2021). 2020. https://istio.io/v1.5/blog/ 17. “Jaeger: Open source, end-to-end
9. A. Noonan. “Goodbye microser- 2020/istiod/ (accessed May 28, distributed tracing.” JaegerTracing
vices: From 100s of problem children 2021). .io. https://www.jaegertracing
to 1 superstar.” Segment, July 2018. 13. “Kubernetes—Production-grade con- .io/ (accessed May 28, 2021).
https://segment.com/blog/goodbye\ tainer orchestration.” Kubernetes.io. 18. S. Newman, Monolith to Microser-
-microservices/ (accessed May 28, 2021). https://kubernetes.io/ (accessed May vices: Evolutionary Patterns to
10. C. Posta. “Istio as an example of when 28, 2021). Transform Your Monolith. Sebasto-
not to do microservices,” Jan. 2020. 14. L. Calcote, The Enterprise Path pol, CA: O’Reilly, 2020.
https://blog.christianposta.com/ to Service Mesh Architectures. 19. O. Zimmermann. “A definition of
microservices/istio-as-an-example O’Reilly, 2018. (accessed May 28, done for architectural decisions.”
-of-when-not-to-do-microservices/ 2021). Medium, May 2020. https://medium
(accessed May 28, 2021). 15. “EnvoyProxy.io.” Envoy. https:// .com/olzzio/a-definition-of-done
11. “Istio—Connect, secure, control, and www.envoyproxy.io/ (accessed -for-architectural-decisions-426cf5
observe services.” Istio.io. https:// May 28, 2021). a952b9 (accessed May 28, 2021).
IEEE TRANSACTIONS ON
BIG DATA
SUBMIT
TODAY
SUBSCRIBE AND SUBMIT
For more information on paper submission, featured articles, calls for
papers, and subscription links visit: www.computer.org/tbd
TBD is financially cosponsored by IEEE Computer Society, IEEE Communications Society, IEEE Computational Intelligence
Society, IEEE Sensors Council, IEEE Consumer Electronics Society, IEEE Signal Processing Society, IEEE Systems, Man &
Cybernetics Society, IEEE Systems Council, and IEEE Vehicular Technology Society
TBD is technically cosponsored by IEEE Control Systems Society, IEEE Photonics Society, IEEE Engineering in Medicine &
Biology Society, IEEE Power & Energy Society, and IEEE Biometrics Council
Digital Object Identifier 10.1109/MS.2021.3099675
22 I E E E S O F T WA R E | W W W. C O M P U T E R . O R G / S O F T W A R E | @ I E E E S O F T WA R E
You can also read
