Skip to main content

Consistency and Availability in Microservice Architectures

  • Conference paper
  • First Online:
Web Information Systems and Technologies (WEBIST 2018)

Part of the book series: Lecture Notes in Business Information Processing ((LNBIP,volume 372))

Included in the following conference series:

  • 495 Accesses

Abstract

For the most part, the first instances of microservice architectures have been deployed for the benefit of the so-called Internet-scale companies in contexts where availability is a critical concern. Their success in this context, along with their promise to be more agile than competing solutions in adapting to changing needs, soon attracted the interest of very diverse classes of business domains characterized by different priorities with respect to non-functional requirements. Microservices embraced this challenge, showing a unique ability to allow for a plethora of solutions, enabling developers to reach the trade-off between consistency and availability that better suits their needs. From a design point of view this translates into a vast solution space. While this can be perceived as an opportunity to enjoy greater freedom with respect to other architectural styles it also means that finding the best solution for the problem at hand can be complex and it is easier to incur in errors that can put a whole project at risk. In this paper we review some possible solutions to address common problems that arise when adopting microservices and we present strategies to address consistency and availability; we also discuss the impact these strategies have on the design space.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Chapter
USD 29.95
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
eBook
USD 39.99
Price excludes VAT (USA)
  • Available as EPUB and PDF
  • Read on any device
  • Instant download
  • Own it forever
Softcover Book
USD 54.99
Price excludes VAT (USA)
  • Compact, lightweight edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Notes

  1. 1.

    https://github.com/Netflix/Hystrix.

  2. 2.

    https://twitter.github.io/finagle/.

  3. 3.

    https://kubernetes.io/.

  4. 4.

    https://github.com/Netflix/conductor.

  5. 5.

    https://zeebe.io.

References

  1. Buschmann, F., Henney, K., Schimdt, D.: Pattern-Oriented Software Architecture. On patterns and Pattern Languages, vol. 5. Wiley, New York (2007)

    Google Scholar 

  2. Rossi, D., Poggi, F., Ciancarini, P.: Dynamic high-level requirements in self-adaptive systems. In: Proceedings of the 33rd Annual ACM Symposium on Applied Computing, pp. 128–137. ACM, New York, NY, USA (2018)

    Google Scholar 

  3. Perry, D.E., Wolf, A.L.: Foundations for the study of software architecture. SIGSOFT Softw. Eng. Notes 17, 40–52 (1992)

    Article  Google Scholar 

  4. Lewis, F., Fowler, M.: Microservices. https://martinfowler.com/articles/microservices.html

  5. Gilbert, S., Lynch, N.: Brewer’s conjecture and the feasibility of consistent, available partition-tolerant web services. SIGACT News. 33, 51–59 (2002)

    Article  Google Scholar 

  6. Coulouris, G., Dollimore, J., Kindberg, T., Blair, G.: Distributed Systems: Concepts and Design. Pearson, Boston (2011)

    MATH  Google Scholar 

  7. Nygard, M.T.: Release It! Design and Deploy Production-Ready Software. Pragmatic Bookshelf, Raleigh (2018)

    Google Scholar 

  8. Burns, B., Oppenheimer, D.: Design patterns for container-based distributed systems. Presented at the 8th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud 16) (2016)

    Google Scholar 

  9. Morgan, W.: What’s a Service Mesh? And Why Do I Need One?. https://dzone.com/articles/whats-a-service-mesh-and-why-do-i-need-one

  10. Kreps, J., Narkhede, N., Rao, J., et al.: Kafka: a distributed messaging system for log processing. In: Proceedings of the NetDB, pp. 1–7 (2011)

    Google Scholar 

  11. Xie, C., et al.: Salt: combining ACID and BASE in a distributed database. In: OSDI, pp. 495–509 (2014)

    Google Scholar 

  12. Boehm, B.W.: Software risk management: principles and practices. IEEE Softw. 8, 32–41 (1991)

    Article  Google Scholar 

  13. Pritchett, D.: BASE: an acid alternative. Queue. 6, 48–55 (2008). https://doi.org/10.1145/1394127.1394128

    Article  Google Scholar 

  14. Vogels, W.: Eventually consistent. Commun. ACM. 52, 40–44 (2009). https://doi.org/10.1145/1435417.1435432

    Article  Google Scholar 

  15. Bailis, P., Fekete, A., Franklin, M.J., Ghodsi, A., Hellerstein, J.M., Stoica, I.: Feral concurrency control: an empirical investigation of modern application integrity. Presented at the Proceedings of the 2015 ACM SIGMOD International Conference on Management of Data, 27 May 2015. https://doi.org/10.1145/2723372.2737784

  16. Garcia-Molina, H., Salem, K.: Sagas. In: Proceedings of the 1987 ACM SIGMOD International Conference on Management of Data, pp. 249–259. ACM, New York, NY, USA (1987). https://doi.org/10.1145/38713.38742

Download references

Acknowledgements

The work presented in this paper was partially supported by the MIUR PRIN 2015 GAUSS Project.

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Davide Rossi .

Editor information

Editors and Affiliations

Appendix

Appendix

Digression 1:

The orchestrator is a microservice, which translates in yet another development project to maintain. Even with the minimal overhead imposed by agile methods the explosion of the number of projects can be troublesome. For this reason (and to improve time-to-market) several approaches based on configurable microservices orchestrators are starting to appear, in some sense we are witnessing the (dreaded) orchestration middleware from E-SOA making its appearance in disguise in the microservices world. Examples include Netflix’s ConductorFootnote 4 (which uses a proprietary DSL) and ZeebeFootnote 5 (which uses BPMN).

Digression 2:

the indirection caused by a messaging infrastructure in often mistaken by logical decoupling. It is true that with these solutions you could, for example, run each component in isolation and that changes in a component providing a function through messaging to another does not imply a change to the latter (which is an usual definition of dependency) but still a malfunction is going to happen so a form of coupling is present. This is because messaging based solution imply a form of hidden interfaces in which a logical dependency still holds between components but interfaces cannot be used as contracts to certify them. This could be summarized in the observation that message-based solutions are more flexible but the price to pay for that is maintenance.

Digression 3:

enhancing existing configurable orchestrators with long-running transaction support seems like a reasonable option. This would essentially result in BPEL for microservices. To the best of the author’s knowledge no product able to do that is currently available (albeit Zeebe seems a good candidate), it will be interesting to see what the future holds in this respect.

Rights and permissions

Reprints and permissions

Copyright information

© 2019 Springer Nature Switzerland AG

About this paper

Check for updates. Verify currency and authenticity via CrossMark

Cite this paper

Rossi, D. (2019). Consistency and Availability in Microservice Architectures. In: Escalona, M., Domínguez Mayo, F., Majchrzak, T., Monfort, V. (eds) Web Information Systems and Technologies. WEBIST 2018. Lecture Notes in Business Information Processing, vol 372. Springer, Cham. https://doi.org/10.1007/978-3-030-35330-8_3

Download citation

  • DOI: https://doi.org/10.1007/978-3-030-35330-8_3

  • Published:

  • Publisher Name: Springer, Cham

  • Print ISBN: 978-3-030-35329-2

  • Online ISBN: 978-3-030-35330-8

  • eBook Packages: Computer ScienceComputer Science (R0)

Publish with us

Policies and ethics