March 11, 2024
Volume 22, issue 1

  PDF

Challenges in Adopting and Sustaining Microservice-based Software Development

Organizational challenges can be more difficult than technical ones.

Padmal Vitharana and Shahir A. Daya

MS (microservice) has become the latest buzzword in software development,^1,6,17 and the popularity of MS-based development is gaining momentum. The MS approach to software development offers an alternative to the conventional monolith style. While benefits of MS-based development over monolith style are clear, industry experts agree that neither style provides an absolute advantage in all situations. Proponents contend that an MS approach to software development more readily facilitates mapping organizational changes manifesting from a more dynamic business environment to corresponding IT/IS (information technology/information systems) changes.

MS represents an architectural style where large, complex applications are composed of a suite of smaller MSs. MSs have been advocated to overcome some of the perils of existing approaches to software development.^1,7,30 Each MS corresponds to a single function around a business capability. Each encompasses its own data resources and is quickly deployable. Examples range from online bill payment on a banking website to an alternate-flights service on an airline website.

Other benefits of MSs include ease of requirements changes and testing, greater scalability, enhanced technology innovation and heterogeneity (e.g., support for different programing languages and platforms), ease of monitoring performance such as service reliability, and support for more process variations.^4,7,18,29 In a previous article in acmqueue, Tom Killalea highlighted eight dividends of microservices beyond the benefits already accepted by industry experts.¹⁵ Extensive adoption by notable companies such as Netflix and Uber has given further credence to MS-based software development.^13,16,19

Thanks to the favorable reviews of MSs, many organizations are now considering adopting them. While benefits are clear, there are significant challenges to adopting and sustaining MS-based software development. Many of these challenges stem from the novelty of the approach and the lack of understanding in both technical and organizational parameters affecting MS-based development. Unless these challenges are well understood, companies are unlikely to reap the full benefits of MSs and be even worse off than before the modernization.

This article identifies key challenges from the initial decision to adopt MSs to the ongoing task of sustaining the new paradigm over the long haul. It aims to provide insights to those considering MS-based software development. This work is supplemented by sections throughout the article labeled "Field Report," which are based on first-hand experiences of one of the authors, Shahir A. Daya, who has been leading significant MS-based development projects for the past two years at several Fortune 100 companies. (He is responsible for helping the IBM Global Business Services organization adopt the skills necessary to deliver MS-based modernization projects. As such, he teaches several classes on the subject and has coauthored an IBM Redbook as well as IBM’s Microservices Decision Guide.)

 

The Initial Decision to Adopt MS Architecture

For many, the decision to adopt MS architecture generally emanates from out-of-control codebases in large and complex monoliths.²³ While many applications start small and are expected to fulfill a specific business need, over time they become larger and more complex as new requirements are added and bugs are fixed. Code refactoring to counter the effects of mounting complexity is often pursued, but barriers to refactoring in a monolith setting are well known.^1,25 Ultimately, the decision to adopt MS architecture rests on the profile of the organization’s application suite.

Although extreme cases of spiraling codebases and escalating complexities are likely to be self-evident, other situations complicate the decision to adopt MSs. In practice, the decision should not be based on transforming all monolithic applications all at once to MSs; rather, the first step should be identifying specific business functionalities and associated code segments as initial candidates for modernizing to MSs. Monolithic applications create enormous bottlenecks when frequent code changes warrant the need to deploy them often.

When applications are already subjected to significant enhancements in a relatively short period of time or are expected to be in the future, management should consider adopting MSs. The case for modernizing to MSs should also be made when monoliths take up greater testing resources than the development effort. When an application is identified as a differentiator in the industry and significant investment has been made for its success, the case ought to be made for refactoring it under MSs. When monolithic applications continue to struggle to meet NFRs (nonfunctional requirements) and user expectations, there are more opportunities to reap the benefits of modernizing to MSs. When a higher value is placed on software scalability, refactoring to MSs allows each MS to be scaled independently of the others that make up the application (vis-à-vis a monolith). While scalability in general is desirable, predicting future scalability requirements is not trivial.

Nonetheless, the biggest challenge for MS proponents is to make the value proposition to upper management. The key to making the case for adoption lies in quantifying the benefits of MS and comparing them with costs of implementing an MS infrastructure, including recruiting and retraining personnel. The decision to modernize to MSs has to take into account all parameters in a holistic, rather than a piecemeal, fashion. Intangibles such as changes to the organizational culture, where a team of individuals is responsible for each MS from development to operation, need to be considered as well.

While the MS model offers greater resiliency in terms of the overall system’s ability to continue to function even when a noncritical MS fails,⁷ it still needs to be programmed into the code.¹² Unlike a single monolith, MSs allow for setting more finely granular SLAs (service-level agreements). When SLAs for an individual MS are considered for the system as a whole, however, they become multiplicative instead of additive from an end-user point of view. Hence, quantifying SLAs for an application made up of a suite of MSs depending on each other can be quite challenging.

As companies look for ways to cope effectively with organizational changes that manifest from a demand such as new product development and the corresponding IT/IS changes, MSs offer a novel approach to align organizational and IT/IS changes more seamlessly.^7,18,29 For many, however, the decision to adopt the MS architecture is not a trivial one, and not all applications are candidates for this modernization.

In comparing monolith and MS approaches to software development, Thomas Hunter, author of Advanced Microservices,¹⁴ asserts that "there are various reasons to choose one approach instead of the other, and neither approach is absolutely better or worse than the other." When a company has a large suite of applications that historically have had one or two deployments a year, there is little reason to make the leap to MSs. In making this important decision to adopt the new paradigm, companies need to examine their application portfolio and consider all aforementioned criteria. Over time, the experience will help organizations navigate the decision-making landscape to either adopt MSs or retain the conventional monolith-based development.

 

 

Converting Existing Monoliths to Microservices

To realize the benefits of the MS paradigm, companies look for ways to break up their existing monoliths. Practically, it makes sense to identify larger MSs that could later be broken into smaller ones. Our experience is that breaking a larger MS into smaller ones is easier than combining two smaller MSs to create a larger one. Others have made similar observations, that most organizations tend to start with bigger MSs and then split them up into smaller ones.²⁶ The challenge is to develop guidelines for systematically carving MSs out of the monolith.

Segmenting code into units where each represents a single function or business capability is referred to as bounded context, a term that has roots in domain-driven design.^3,9 Isolating frequently changing code segments within a monolith serves as the starting point in identifying bounded context for segmenting part of the monolith to create MSs. As alluded to earlier, the code segments that (a) are most used, (b) take up significant testing resources, (c) serve as differentiators, and (d) struggle to meet NFRs and user expectations also provide clues about how to segment a monolith to build MSs.

This transformation exercise requires adherence to conventional principles in strong cohesion and loose coupling. Nonetheless, the goal should never be to convert the entire monolith into MSs. Instead, in an iterative fashion, suitable code segments should be identified and refactored into MSs.

Implementing stopping rules for the monolith-to-MS transformation plays a crucial role in reaching desired objectives without getting carried away by MS mania. Moreover, this should not be an exercise in simply copying a codebase from a monolith and pasting it to an MS. It needs to be looked upon as an opportunity (albeit with certain challenges) to improve that code segment in the form of an MS that provides a specific business function with a well-defined interface.

In most instances, not all of the original monolith is converted to MSs. The overhauled monolith now has to coexist with newly created MSs. Calls that initially went to the monolith may now have to be rerouted to the corresponding MS. The new ecosystem creates an added challenge that is not present in a solely monolithic environment: The user interface of the existing monolith needs to be updated to point modernized/new functions to the MS-based application delivering that business function. This coexistence of the monolithic application and the MS-based modernized parts requires sharing context between them, including authentication/authorization information, thereby further exacerbating complexities in software development and operation.

Breaking up a monolith invariably involves segmenting data elements in the enterprise repository to individual MSs. While designers are generally well versed in principles of distributed database design, the new ecosystem consisting of monoliths and MSs requires training in data segmentation that transcends our extant knowledge. In this exercise, the challenge is to avoid data duplication and possibly learn to disregard conventional principles such as data normalization. Once data is partitioned, the monolith has to be tested to make sure that it does not break. While each MS containing its own data resources has it benefits, practitioners face significant challenges in partitioning the enterprise database.

MS-based development requires additional levels of testing. First, contract testing refers to testing APIs. When a consumer links to an MS, a contract is formed. This contract defines the inputs, outputs, and performance parameters that need to be thoroughly tested.

Second, chaos testing refers to testing for "chaos" inherent in the natural world. Generally, this exercise involves defining what is "normal" and testing the system under those conditions before introducing chaotic conditions. More chaotic conditions manifest in the new paradigm because unlike a monolith, which has only two states of availability, some of the MSs in the application might be up and running while the others may not.

To mimic this reality in chaos testing, each MS is brought down deliberately to test its implications on the overall system. This testing also involves intentional introduction of network latency to assess its impact on performance. MSs communicate with each other over the network as opposed to the in-process function calls made in a monolith. Testing circuit breakers¹¹—put in place to decide whether to continue operating under normal conditions or resort to operating under limited capacity—places added complexities on the emerging paradigm.

 

 

Building New Microservices and Modifying Existing Ones for New Requirements

As new requirements emerge, developers have to decide whether to build a new microservice or modify an existing one. When modifying an existing MS, the challenge is to preserve the bounded context of that MS (i.e., high cohesion of what is included in the MS). Unless developers are trained in the new paradigm, they could resort to what is technically expedient rather than maintaining core principles of MS-based development by focusing on business aspects. For example, adding new code to satisfy a requirement might break the tenet that each MS should support a single function around a business capability. Or lack of due diligence in adding code might result in unintentional dependencies (i.e., coupling between the modified MS, other MSs, or even the refactored monolith), thereby stymying the ability to independently and quickly change, test, and deploy it.

The key is to educate developers to handle business requirements in the new paradigm and instill discipline to maintain its fundamental tenets. The technical lead in each development team needs to verify that creating new MSs and modifying existing ones does not break key assumptions of the emerging paradigm. Conventional techniques such as code reviews need to be expanded to ensure that the new configuration does not violate the bounded context. Failure to do so would result in the breakdown of the MS architecture and thwart the realization of its much-touted benefits.

The new paradigm operates at the application level rather than at an enterprise level, as is the case with SOA (service-oriented architecture) and web services. Hence, there could be some duplication of effort. Although one application team might have created an MS that could be used by a second application team, in the absence of an enterprise-wide repository of MSs, the latter might create an identical MS.

These application-based teams tend to move at a fast pace and tend to do little sharing of codebases among them. The modest sharing that does occur manifests by word of mouth or through personal contacts among developers and project teams. In case one team finds an MS already created by another team useful, the former team tends to create its own "copy" of the existing MS to avoid being dependent on the MS created by the latter team. The team essentially forks the codebase and is now responsible for maintaining its own fork of the MS. The best way to promote sharing, however, is to catalog all MSs.

The addition of new MSs creates new challenges in monitoring them. Developers have to define metrics for monitoring performance of MSs. One key question is to define what it means to say that an MS is in "good" standing. Monitoring MSs for their availability, reliability, ability to fulfill SLAs, robustness, and resiliency requires metrics and benchmarking. It might require creating synthetic transactions to test the health of each MS periodically. Performance logs of MSs need to be continually monitored to assess their performance and take corrective action when needed.

 

 

Operating Microservices and the Architecture

The MS paradigm creates greater operational complexity because of the numerous moving parts that need to be tracked (vis-à-vis conventional monoliths). Each MS provides a specific business functionality and a suite of MSs have to work in concert to provide a more overarching business function. While MS-based development relies on developing autonomous services offering some business functionality, designing decoupled application systems is no easy task. It involves messaging and data exchange among corresponding MSs that need to be monitored and managed. Unlike maintaining enterprise databases commonly used with monolith systems, maintaining the availability and consistency of data partitioned into MSs creates additional demands.

Versioning brings significant challenges in the new paradigm. Instead of having to deal with a few versions of a monolith, now developers and analysts have to deal with multiple build and interface versions of many MSs.²⁰ As developers create new versions, they have to provide support for both prior and new versions. Users need to be informed of differences with older versions in terms of functionality and interface. Some developers choose to list a new MS as experimental, beta, or general.⁷ There must be clear guidelines for informing users in case of discontinued support for older MSs. When the service registry contains multiple versions of an MS, locating the right one for a given application creates additional complications. Versioning strategies and guidelines need to be in place.

The network has a greater effect on an application with many MSs as opposed to a single monolith where function calls are in the same running process.⁸ Networks inherently introduce latency issues that could adversely impact the performance of an MS-based application. MSs manifest in the form of distributed systems with calls among them managed via the network. Unlike monoliths, an application consisting of a suite of smaller MSs with messaging among them could amplify network latency.

Running performance tests to identify the biggest sources of latency could hold the key to addressing this challenge. Choosing a platform that helps identify potential bottlenecks could ease network latency. While network latency is unavoidable when dealing with applications composed of MSs, greater insights into the inner workings of MSs would aid in identifying markers on acceptable latency levels.

In addition to technical challenges, companies face obstacles to changing the prevailing culture surrounding monoliths when they begin to develop MSs, where incentives and accountability differ considerably. The new paradigm promotes principles of DevOps teams that are charged with both developing and operating each MS. DevOps correspond to a set of practices that strive to unify software development (Dev) and software operation (Ops).²

Unlike conventional teams based on disciplines such as marketing, DevOps teams are organized by business capabilities. They are responsible from inception to the entire operational life of a product, whether it is small or an end-to-end vertical slice through the product implementing a feature of a larger product that includes all of the MSs that are part of it.

Instead of seeking technology-focused solutions in monoliths, these DevOps teams seek business service-focused solutions. Before an MS is implemented, a clear business service (i.e., function) that the MS is expected to represent has to be delineated. The cultural changes, such as willingness to work with cross-functional teams and to take on expanded roles demanded by the emerging paradigm, are likely to face resistance from some quarters. Moving to a new culture based on the principle "if you build it, you run it and support it" could prove challenging. Unless the incentives are aligned to promote cross-functional collaboration and accept expanded roles as in DevOps teams, some may be reluctant to embrace the organizational changes necessary to facilitate MS-based development.^7,28

 

Field Report

While working at different organizations to deliver MS-based projects, we have found that the organizational challenges are much more difficult than the technical challenges. Putting together a cross-functional team/squad that can handle a vertical slice right from the UI to the back end across all of the channels (web, mobile, etc.) is not an easy task. These individuals are likely to be in different parts of the organization and may need to be moved to overcome some of the barriers. Moving all of the individuals who make up a team so they report to the same HR manager certainly helps. Although they have the same HR manager, team members will take technical directions from different leads based on their given roles in the cross-functional team.

Developers also need to get up to speed with the Ops part of DevOps. The team has to accept the fact that they maintain and support the code they write. If the MS they write fails, they will get paged in the middle of the night. They need to implement the necessary monitoring, dashboarding, alerting, and runbook automation to avert such emergency interruptions. We are starting to do this with our clients and are seeing positive results. Developers are taking ownership, and code quality is improving, but developers don’t want to maintain their code forever. It is critical to keep them engaged, so it is important to let individuals move from one team/squad to another, one at a time.

Having strong executive sponsorship at the organization for your MS initiatives is absolutely necessary for success. All of our clients experiencing positive forward movement in the cultural transformation have strong executive sponsorship.

 

Sustaining a MicroserviceS Approach in the Long Haul

As with any new paradigm, the use of MSs for software development and operation warrants justification on a periodic basis. Top management is likely to insist on evidence of performance gains in order to furnish ongoing investment in people and MS-related technology. This requires initial benchmarking and continuous performance assessment.

While conventional metrics have relevance, new performance metrics need to be developed and instituted. For example, SLAs for an MS-based application as well as SLAs for each MS must be tracked for compliance. In addition to these traditional nonfunctional requirements, other baselining and tracking metrics include an increase in deployments with the modernized application, reduction in the amount of downtime during deployments, reduction in the number of defects/bugs being reported, decrease in the cost of making updates to add new features, etc.

Moreover, processes need to be in place to review and refine applications and MSs within each application. Fundamentally, each MS is expected to represent a single business functionality. Checks and balances are needed to confirm that each MS conforms to this core principle. Generally, companies have not instituted such processes, although there is tremendous value in doing so in order to attest that the company stays true to itself in embracing the new paradigm. Often when existing MSs are modified, some may contain meta functionality and dependencies (i.e., tight coupling) with other MSs—two characteristics that are contrary to guiding principles of MS-based development.

On a periodic basis, each MS should be inspected by a different party from the one that developed it to make sure it complies with key tenets of MS-based development. The same holds true for data embedded in MSs. Without clear focus and discipline, revising existing MSs to add a new requirement or fix a defect might result in unwanted data dependencies between MSs and enterprise databases.

With ongoing pressure to move software products out the door, some developers might be tempted to cut corners and abandon the founding tenets of MSs in the process. The developer pool needs continuous training in maintaining core principles of MS-based development.

Moreover, companies need to continue building talent to develop the next generation of MSs that correspond to a single function around a business capability, encompass their own data resources, and are quickly deployable. However, few college graduates receive training in MS-based software development. These are some of the challenges organizations face in sustaining MS-based development over the long run.

 

 

Conclusion

Increasing globalization and hypercompetition have resulted in dynamic business environments that require companies to adapt quickly to rapid and frequent changes. These environmental forces necessitate changes to business strategy that manifest in internal organizational changes. Software systems are intimately intertwined with all aspects of a company and, therefore, organizational changes warrant system changes.^4,7,21,24

Companies continue to struggle, however, with effectively mapping organizational changes with IT/IS changes.^7,29 This has been attributed to a company’s inability to deploy software applications independently and quickly.⁷ The software industry is enamored with MS-based development’s ability to overcome these perils.

Each MS contains its own data and represents a single function that corresponds to a business capability. This allows for seamless alignment of business services with software services (i.e., microservices). While the new paradigm has considerable advantages, it can impose substantial costs as well.^1,7,22,27 Hence, the challenges highlighted in this article have to be considered to improve a company’s chances of success in adopting and sustaining MS-based software development.

 

References

1. Abgaz, Y., McCarren, A., Elger, P., Solan, D., Lapuz, N., Bivol, M., Jackson, G., Yilmaz, M., Buckley, J., Clarke, P. 2023. Decomposition of monolith applications into microservices architectures: a systematic review. IEEE Transactions on Software Engineering 49(8), 4213–4242; https://dl.acm.org/doi/10.1109/TSE.2023.3287297.

2. Balalaie, A., Heydarnoori, A., Jamshidi, P. 2016. Microservices architecture enables DevOps: migration to a cloud-native architecture. IEEE Software 33(3), 42–52; https://dl.acm.org/doi/10.1109/MS.2016.64.

3. Bogner, J., Zimmermann, A. 2016. Towards integrating microservices with adaptable enterprise architecture. IEEE 20th International Enterprise Distributed Object Computing Workshop, 158–163; https://ieeexplore.ieee.org/document/7584392.

4. Bozan, K., Lyytinen, K., Rose, G. 2021. How to transition incrementally to microservice architecture. Communications of the ACM 64(1), 79-85; https://dl.acm.org/doi/10.1145/3378064.

5. Brown, K. 2017. Apply the Strangler Fig application pattern to microservices applications. IBM; https://developer.ibm.com/articles/cl-strangler-application-pattern-microservices-apps-trs/.

6. Cortellessa, V., Di Pompeo, D., Eramo, R., Tucci, M. 2022. A model-driven approach for continuous performance engineering in microservice-based systems. Journal of Systems and Software 183; https://www.sciencedirect.com/science/article/pii/S0164121221001813.

7. Daya, S., van Duy, N., et al. 2016. Microservices from Theory to Practice: Creating Applications in IBM Bluemix Using the Microservices Approach. IBM Redbooks; https://www.redbooks.ibm.com/abstracts/sg248275.html.

8. Dragoni, N., Saverio, G., Lafuente, A.L., Mazzara, M., Montesi, F., Mustafin, R., Safina, L. 2017. Microservices: yesterday, today, and tomorrow. In Present and Ulterior Software Engineering. Springer, 195–216; https://link.springer.com/chapter/10.1007/978-3-319-67425-4_12.

9. Evans, E. 2004. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional.

10. Fowler, M. 2004. Strangler Fig application; https://martinfowler.com/bliki/StranglerFigApplication.html.

11. Fowler, M. 2014. Circuit breaker; https://martinfowler.com/bliki/CircuitBreaker.html.

12. Hasselbring, W. 2016. Microservices for scalability: keynote talk abstract. Proceedings of the Seventh ACM/SPEC on International Conference on Performance Engineering, 133–134; https://dl.acm.org/doi/10.1145/2851553.2858659.

13. Hoff, T. 2016. Lessons learned from scaling Uber to 2000 engineers, 1000 services, and 8000 git repositories. High Scalability; https://goo.gl/1MRvoT.

14. Hunter, T. 2017 Advanced Microservices: A Hands-on Approach to Microservice Infrastructure and Tooling, page 1. APress.

15. Killalea, T. 2016. The hidden dividends of microservices. acmqueue 14(3); https://queue.acm.org/detail.cfm?id=2956643.

16. Mauro, T. 2015. Adopting microservices at Netflix: lessons for architectural design. NGINX; https://goo.gl/DyrtvI.

17. Mendonça, N., Jamshidi, P., Garlan, D., Pahl, C. 2021. Developing self-adaptive microservice systems: challenges and directions. IEEE Software 38(2), 70–79; https://dl.acm.org/doi/10.1109/MS.2019.2955937.

18. Newman, S. 2020. Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith. O’Reilly Media.

19. Panda, A., Mooly, S., Shenker, S. 2017. Verification in the age of microservices. Proceedings of the 16th Workshop on Hot Topics in Operating Systems, 30–36; https://dl.acm.org/doi/10.1145/3102980.3102986.

20. Pautasso, C., Zimmermann, O., Amundsen, M., Lewis, J., Josuttis, N. 2017. Microservices in practice, part 2: service integration and sustainability. IEEE Software 34(2), 97–104; https://dl.acm.org/doi/10.1109/MS.2017.56.

21. Rolland, K., Lyytinen, K. 2021. Managing tensions between management of architectural debt and digital innovation: the case of a financial organization. Proceedings of the 54th Hawaii International Conference on System Sciences, 6722–6732; https://scholarspace.manoa.hawaii.edu/server/api/core/bitstreams/5b283564-2e92-4c36-abf3-519e72d0fd0b/content.

22. Singleton, A. 2016. The economics of microservices. IEEE Cloud Computing 3(5), 16–20; https://ieeexplore.ieee.org/document/7742218.

23. Taibi, D., Lenarduzzi, V., Pahl, C. 2017. Processes, motivations, and issues for migrating to microservices architectures: an empirical investigation. IEEE Cloud Computing 4(5), 22–32; https://ieeexplore.ieee.org/document/8125558.

24. Tallon, P. P., Queiroz, M., Coltman, T., Sharma, R. 2016. Business process and information technology alignment: construct conceptualization, empirical illustration, and directions for future research. Journal of the Association for Information Systems 17(9), 563–589; https://aisel.aisnet.org/jais/vol17/iss9/3/.

25. Tempero, E., Gorschek, T., Lefteris, A. 2017. Barriers to refactoring. Communications of the ACM 60(10), 54–61; https://dl.acm.org/doi/10.1145/3131873.

26. Thönes, J. 2015. Microservices. IEEE Software 32(1), 116; https://dl.acm.org/doi/10.1109/MS.2015.11.

27. Waseem, M., Liang, P., Shahin, M. 2020. A systematic mapping study on microservices architecture in DevOps. Journal of Systems and Software 170; https://www.sciencedirect.com/science/article/abs/pii/S0164121220302053.

28. Waxer, C. 2015. Microservices mania. Computerworld 2(4), 22–27; https://www.computerworld.com/article/2998269/read-cw-s-november-monthly-digital-magazine.html.

29. Wolff, E. 2017. Microservices: Flexible Software Architecture. New York: Addison-Wesley.

30. Zhou, X., Li, S., Cao, L., Zhang, H., Jia, Z., Zhong, C., Shan, Z. Babar, M. A. 2023. Revisiting the practices and pains of microservice architecture in reality: an industrial inquiry. Journal of Systems and Software 195(C); https://dl.acm.org/doi/10.1016/j.jss.2022.111521.

 

Acknowledgments

This research was funded by grants from the Robert H. Brethen Operations Management Institute and the Earl V. Snyder Innovation Management Center at the Whitman School of Management, Syracuse University.

 

Padmal Vitharana is a professor of information systems in the Martin J. Whitman School of Management at Syracuse University. He received his Ph.D. from the University of Wisconsin-Milwaukee. His research expertise lies in system analysis and design in general and microservices, software components, and services in particular. His research has been published in leading journals, and he has served on the editorial boards of IEEE Transactions on Services Computing and Communications of the AIS.

Shahir A. Daya is an IBM Distinguished Engineer and chief architect for Business Transformation Services at IBM Canada. He is an IBM senior certified architect and an Open Group distinguished chief/lead IT architect with more than 25 years at IBM. He has received the prestigious IBM Corporate Award for exceptional technical accomplishments. His industry experience includes banking, financial services, and travel and transportation. He focuses on cloud-native architecture and modern software engineering practices for high-performing development teams.

Copyright © 2024 held by owner/author. Publication rights licensed to ACM.

Originally published in Queue vol. 22, no. 1—
Comment on this article in the ACM Digital Library

---

---

---

© ACM, Inc. All Rights Reserved.