Microservices Case Study

resources.docx

Home >Architecture and Design homework help >Microservices Case Study

From service-oriented to microservice architecture

Introduction:

It would be remiss not to make some form of reference to Monoliths and monolithic architecture in the introduction of this material, as microservices are frequently designed and developed to replace monolithic platforms and we will be reviewing techniques to manage this process over the duration of this subject. One of the key cornerstones of software engineering relates to determining sound principles of software architecture. Understanding the role of the architect and decision-making is covered in the essential resources, as is the concepts of monoliths and monolithic architectures and their innate challenges. This is to ensure that you have a basis of comparison and frame of reference for later topics.

The emergence of web services and communication models leveraging APIs was a step change in the principles of software engineering architecture. This heralded the emergence of a service-based architecture model otherwise known as service-oriented architecture. The fundamental concepts of service-oriented architecture are covered in support of developing an understanding how single-tiered systems evolved into multi-tiered solutions before the revolutionary paradigm shift to microservices architectures. It is important to note that while both service-oriented architecture and microservices architecture are considered service-based architectures there are very specific differences between these methods. While both focus on the creation of services, microservices architecture is a far more fine-grained approach to software development. As we progress through the subject, we will discuss how microservices architecture has changed the face of software engineering particularly in environments that require rapid scalability and demands continuous development and deployment.

Resources and Activities:

video icon

What is software architecture?

Please watch the following video from the Software Architecture Foundations series:

1. Introduction - What is software architecture? (3m 54s)

In this short video clip, you are introduced to the fundamentals of software architecture. It has an interesting analogy about what architects do and how they describe entire systems that helps businesses achieve their goals and objectives in an efficient and effective manner by tailoring them to their use.

Reference:

Holub, A. (2019, March 19). Introduction: What is software architecture? [Video file]. Retrieved from https://www.linkedin.com/learning-login/share?forceAccount=false&redirect=https%3A%2F%2Fwww.linkedin.com%2Flearning%2Fsoftware-architecture-foundations%3Ftrk%3Dshare_ent_url&account=56744473

video icon

Monoliths

Please watch the following video from the Software architecture foundations series:

1. 5.Broad architectural patterns: Monoliths (6m 48s)

In this short video clip, you are introduced to the concept of monolithic systems which have a monolithic software architecture. As past systems were dominated by monolithic architectural patterns, this video clip helps you to understand what monolithic architectural patterns are and their benefits and drawbacks. It is important for you to understand this concept from a comparative perspective as while software architecture is evolving, monolithic systems remain as core systems within many businesses, and it is likely that you will be professionally active in businesses that either remain dependent on these systems, or who are in transition to newer forms of software architecture.

Reference:

Holub, A. (2019, March 19). Broad architectural patterns: Monoliths [Video file]. Retrieved from https://www.linkedin.com/learning-login/share?forceAccount=false&redirect=https%3A%2F%2Fwww.linkedin.com%2Flearning%2Fsoftware-architecture-foundations%3Ftrk%3Dshare_ent_url&account=56744473

video icon

The monolithic application

Please watch the following video from the Microservices Foundations series:

1. 1.About microservices: The monolithic application (4m 7s)

This short video clip introduces you to some of the key challenges associated with monolithic applications when updates or changes are required to existing functionality. Please pay specific attention to the reasons for inflexibility of these systems and why these present challenges for developers that impact on speed to market and deployments of new code.

Reference:

Molley, F. (2018, February 9). About microservices: The monolithic application [Video file]. Retrieved from https://www.linkedin.com/learning-login/share?forceAccount=false&redirect=https%3A%2F%2Fwww.linkedin.com%2Flearning%2Fmicroservices-foundations%3Ftrk%3Dshare_ent_url&account=56744473

readings icon

Service-oriented Architecture: Introduction

Please read the preface and introduction on pages 1-3. In this short reading you are introduced to the two service-based architectures: service-oriented architecture and microservices architecture. It has an interesting section on what service-oriented architecture is, why it is implemented and why there has been a shift from monolithic applications. While there are references to distributed object-oriented programming models – understanding these is not key to understanding service-oriented and microservices architecture. Pay particular attention to is a high-level definition of service-based architecture models.

Reference:

Surianarayanan, C., Ganapathy, G., & Pethuru, R. (2019). Essentials of microservices architecture: Paradigms, applications, and techniques. Florida, USA: Taylor & Francis Group. Retrieved from https://ebookcentral-proquest-com.ezproxy.laureate.net.au/lib/think/reader.action?docID=5883406&ppg=23

readings icon

Concepts of Service-Oriented Architecture

Please read pp. 10 - 12. In this short reading you are introduced to the key concepts of service-oriented architecture. It has an interesting section on why service-oriented architecture can meet different needs within an enterprise. Pay attention to the 5 reasons why enterprises would gain benefit from service-oriented architecture and why integration between applications offers value to enterprises.

Reference:

video icon

Microservices 101

Please watch the following video from Cloud architecture: Advanced concepts series:

1. 2.Leveraging microservices architecture: Microservices 101 (3m 16s)

This video clip gives you insights into what microservices are and how they support business functions. It discusses how microservices have high utility and use communications calls to fetch required information from a variety of services. The specific inclusion of this video is to help you understand how microservices are flexible and decomposed services that belong either to applications or services that allow functions to be performed.

Reference:

Linthicum, D. (2019, January 23). Leveraging microservices architecture: Microservices 101. [Video file]. Retrieved from https://www.linkedin.com/learning-login/share?forceAccount=false&redirect=https%3A%2F%2Fwww.linkedin.com%2Flearning%2Fcloud-architecture-advanced-concepts-2%3Ftrk%3Dshare_ent_url&account=56744473

readings icon

A Solution Approach

Please read section pp. 1 - 12. In this short reading you are introduced to how microservices have evolved, transforming from service-oriented architecture and as a response to the limitations of monolithic architectures. The diagrams of page 6 and 7 give you clear insights as to the core differences between these architectural approaches, and this requires particular attention.

Reference:

Sharma, S., RV, R., & Gonzalez, D. (2016). Microservices: Building Scalable Software. Birmingham, UK: Packt Publishing. Retrieved from http://search.ebscohost.com.ezproxy.laureate.net.au/login.aspx?direct=true&db=nlebk&AN=1460302&site=ehost-live&authtype=ip,sso&custid=ns251549&ebv=EB&ppid=pp_3

Additional Learning Resources

If you would like to learn more about the topics covered in this module, here are some additional resources. These resources will contribute to further develop your understanding of the topics covered. However, these resources are not essential to complete this module or the assessments associated with this subject.

readings icon

Web Services

Please read the introductory paragraph on p. 13 and the section on the unique capabilities of web services on pp. 15 – 16 and the section ‘Why Do We Need Web Services’ on pp. 16-18. This short reading is to ensure that you have a basis of understanding of how web services support communications between applications. You will develop knowledge in that will form a basis of comparison between communications models in web services vs. microservices.

Reference:

readings icon

Seven reasons to switch to microservices – and 5 reasons you might not succeed.

While microservices may sound like a panacea for many of the challenges posed by monolithic systems and their rigid architectures, microservices can be complex and the transition will require careful thought. This article speaks to some of the practical challenges of shifting to a microservices software architecture. Please note, this will offer you key departure points for your assignment.

Reference:

Bertram, A. (2017, June). Seven reasons to switch to microservices – and 5 reasons you might not succeed. CIO. Retrieved from https://www.cio.com/article/3201193/7-reasons-to-switch-to-microservices-and-5-reasons-you-might-not-succeed.html

readings icon

Microservices: first break down monolithic thinking, then monolithic applications

This article offers insights into how connectivity and communications between microservices is vital for their function and how a shift to microservices not only changes how the organisation architects its software, but also changes corporate culture by requiring a more Agile organisation – this will tie in to further discussions about DevOps and agile software development practice in later modules.

Reference:

McKendrick, J. (2018, March 27). Microservices: first break down monolithic thinking, then monolithic applications. ZDNet. Retrieved from https://www.zdnet.com/article/manual-database-deployment-processes-inhibits-application-delivery/

principles and key concepts of microservices

Introduction:

British software development specialists Martin Fowler and James Lewis describe microservices architecture as:

“In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.” (Fowler,2014)

It is fair to note that microservices architecture is a developing field, and in some ways might be considered more of a philosophy for software engineering than a fully defined and developed methodology now. However, there is consensus on the characteristics of applications built using microservices architecture principles:

1. Size – they are smaller than service-oriented architecture and much smaller than monoliths

2. Communications – they rely on messaging to call information from other microservices

3. Context – is bounded, most often by defined functionality of the microservices

4. Autonomous – the are developed to meet a specific purpose sharing as little as possible with other services

5. Deployment – does not rely on any other service and is therefore independent

Microservices architecture evolved through the pursuit of software engineering that allowed speed of change, safety of change – at scale – and in harmony.

There is a clear value proposition:

1. Teams do not depend on each other for delivery and can develop and ship code faster by being freed from interdependencies

2. As teams are not independent, various services can be developed in parallel

3. Without interdependencies, the tech stack of technologies, languages and frameworks can differ from one service to another and can be selected on best suitability for the service in question rather than seeking a middle ground unified approach

4. Because it is easy to simply replace an independent service, code can become ‘disposable’ – what doesn’t work can be easily replaced

In this module we will work through some of the fundamental philosophies, concepts and principles of microservices architecture before we progress into developing our deeper understanding of how microservices has changed many different facets of software engineering.

References

1. Fowler, M. (2014, March 25). Microservices – A definition of this new architectural term. Retrieved from https://martinfowler.com/articles/microservices.html

Resources and Activities:

video icon

The concepts behind microservices

Please watch the following video from the DevOps foundations: Microservices series:

1. 1.Microservices in production: The concepts behind microservices (3m 6s)

In this short video clip, you are introduced to the key concepts of microservices. Note how microservices can be very broad and diverse and so not easily defined. Note how the presenter illustrates that services should be organised around a real-world domain and enforced by bounded contexts. Note how teams developing are not split according to function but rather by business capability with the various skill sets blended into a team.

Reference:

Stone, L. (2019, February 27). Microservices in production: The concepts behind microservices. [Video File]. Retrieved from https://www.linkedin.com/learning-login/share?forceAccount=false&redirect=https%3A%2F%2Fwww.linkedin.com%2Flearning%2Fdevops-foundations-microservices%3Ftrk%3Dshare_ent_url&account=56744473

video icon

Microservices

Please watch the following video from the Cloud architecture: Advanced concepts series:

1. 1.Advanced architecture patterns: Microservices (5m 40s)

In this short video clip, you are introduced to how microservices is a new way to define services. It has an interesting section where the facilitator discusses how microservices are a decomposition of prior services that are of a more coarse-grained nature in the interests of creating services that are more useable. Pay particular attention to the definition of how different architectures influence how autonomous and independent services may be from one another and the benefits this creates. Note how he discusses how many, even thousands, or microservices may exist to do the job of what a monolithic application would have done in the past. From the 3:00 minute mark of the video, Linthicum shares a diagram that illustrates how decomposition of monolithic and service-oriented architected systems leads to finer grained services. This creates discrete and independent services.

Reference:

Linthicum, D. (2019, January 23). Advanced architecture patterns: Microservices. [Video File]. Retrieved from https://www.linkedin.com/learning-login/share?forceAccount=false&redirect=https%3A%2F%2Fwww.linkedin.com%2Flearning%2Fcloud-architecture-advanced-concepts-2%3Ftrk%3Dshare_ent_url&account=56744473

readings icon

Microservices

Please read pp. 1 – 8. This will give you a clear idea of what the philosophy of microservices architecture is and its defining characteristics. Please pay particular attention to the primary characteristics: Small and autonomous. Understanding these defining characteristics is pivotal to your further understanding of this philosophy. Thereafter take careful note of the 7 benefits that a microservices architecture philosophy offers software engineers.

Reference:

Newman, S. (2015). Building microservices: Designing fine-grained systems. California, USA: O’Reilly Media. Retrieved from https://ebookcentral-proquest-com.ezproxy.laureate.net.au/lib/think/reader.action?docID=1938300&ppg=21

readings icon

The Microservices Way

Please read pp. 4 – 11. Pay close attention to the three concepts that are outlined as definitive to microservices architecture as a style. From page 6 the authors ask and answer a series of questions about what sets microservices architecture apart from service-oriented architecture and the key characteristics. They define this as ‘The Microservices Way’ and avoid deep diving into the technologies used, while rather speaking to the philosophy. While Newman et al. have focussed on ‘small and autonomous’ Nadareishvili et al. focus on speed, safety and harmony. It is important to note that as this is a philosophy, these ideologies do not conflict with each other, but rather extend philosophical understanding.

Reference:

Nadareishvili, I., Mitra, R., McLarty, M., & Amundsen, M. (2016). Microservice architecture: Aligning principles, practices, and culture. California, USA: O’Reilly. Retrieved from https://ebookcentral-proquest-com.ezproxy.laureate.net.au/lib/think/reader.action?docID=4602504&ppg=19

readings icon

The Microservices Value Proposition

Please read pp. 13 - 16. Nadareishvili et al. Lay out benefits of microservices architecture – these are like those laid out by Newman (2015) but do have some subtle differences while remaining largely philosophically aligned. Please pay attention to the businesses that they use as examples because it offers you a contextual understanding of which businesses are at the forefront of the microservices vanguard and how it allows their business to benefit. Pay specific attention to the 6 ways in which speed contributes to business value – this will be important for your assignment.

Reference:

Additional Learning Resources

If you would like to learn more about the topics covered in this module, here are some additional resources. These resources will contribute to further develop understanding of the topics covered. However, these resources are not essential to complete this module or the assessments associated with this subject.

readings icon

To be a microservice: How smaller parts of bigger applications could remake IT

This resource offers you insights int the main ideas that are driving microservices and the value they can create. It is an ‘easy-read’ trade-based article to offer you a nutshell view of how the industry is viewing microservices architecture as a potential solution to offer more responsive systems development in a rapidly changing world.

Reference:

Fulton, S. (2018, September 7). To be a microservice: How smaller parts of bigger applications could remake IT. ZDNet. Retrieved from https://www.zdnet.com/article/to-be-a-microservice-how-smaller-parts-of-bigger-applications-could-remake-it/

Designing services

Introduction:

Designing microservices leverages systems thinking, design and a capability to manage complexity. In fact, microservices architectures, as discussed in the module introduction have arisen as a philosophy in response to business conditions that give rise to rapidly evolving complexity. Which encourages smaller services that support a plethora of moving parts. Neil Hunt, Chief Product Officer at Netflix describes this as achieving a ‘more nimble architecture’ that ‘improves ‘productivity and scalability’.

So…. how is this achieved?

Newman (2015) outlines several service modelling concepts such as ‘loose coupling’ and ‘high cohesion’. As Microservices architecture is more broadly a philosophy rather than a method, it is important to note and understand these concepts and how they guide the definition of bounded contexts. Both how these may be defined for a new systems as well as established within an existing monolith by identify seams or breaks within the code that may be sheered into a number of services which align to bounded services.

The approach shared in Nadareishvili, Mitra, McLarty and Amundsen (2016) includes a model consisting of five parts to guide the process of service design. While the service itself is the primary concern of this module, in further modules we will review processes and tools, organisation and culture. Please pause on the element of solutions architecture – it is important to note that while this role is vital to support a good overall understanding of services, this role is not involved in the microservices design or architecture, but in the broader view of how these different services come together at a macro level. This differentiation is important to note. (Please note: there are a number of ‘architect’ roles in IS, and it important not to confuse their roles and responsibilities).

The process shown by Nadareishvili et al. (2016) in figure 3.2 offers a practice-based framework for the process of design and allows for iteration to ensure that complexities are explored, and opportunities are taken to consider and resolve complexities as best as possible in addressing constraints and context. Non-essential complexity is to be avoided, with an emphasis being placed on iteration where observations lead to adjustments.

References

1. Nadareishvili, I., Mitra, R., McLarty, M., & Amundsen, M. (2016). Microservice architecture: Aligning principles, practices, and culture. California, USA: O’Reilly. Retrieved from https://ebookcentral-proquest-com.ezproxy.laureate.net.au/lib/think/detail.action?docID=4602504

Resources and Activities:

readings icon

How to model services

Please read pp. 29-38. There are several important service modelling concepts that you need to understand in this section. Firstly, the concepts of ‘loose coupling’ and ‘high cohesion’ are important to achieving successful microservices outcomes. Also, of vital importance is understanding the bounded context of domains within which functionality will sit – pay close attention to the example given, it will give you a clear understanding of how a bounded context assist with the decomposition into services. Note the cautionary elements in the section that speaks to modules and services based on the risks associated with premature decomposition.

Reference:

Newman, S. (2015). Building microservices: Designing fine-grained systems. California, USA: O’Reilly Media. Retrieved from https://ebookcentral-proquest-com.ezproxy.laureate.net.au/lib/think/reader.action?docID=1938300&ppg=50

readings icon

The Systems Approach to Microservices

Please read section pp. 25 - 33. In this short reading you are introduced to the systems approach that needs to be taken to develop applications with microservices. It has an interesting section highlighted in Figure 3-1. To which you should pay particular attention. It shows the five parts of the microservice design model. Please ensure that you read about each part to ensure that you can orient yourself in understanding how the parts of this model work together as we explore each component further.

Reference:

Nadareishvili, I., Mitra, R., McLarty, M., & Amundsen, M. (2016). Microservice architecture: Aligning principles, practices, and culture. California, USA: O’Reilly. Retrieved from https://ebookcentral-proquest-com.ezproxy.laureate.net.au/lib/think/detail.action?docID=4602504

readings icon

A Microservices Design Process

Please read pp. 33- 38. The model shown in Figure 3-2 is key to your understanding of the design process. Please note that as microservices architecture is more of a philosophy than a set of ‘hard and fast’ rules that can be applied to any and all organisations, it is likely that this will be a process that is iterative with carefully balanced trade-offs to achieve optimization goals. It is up to the design team to arrive at development principles which they will use to guide their design, to sketch out how they believe the system should be, followed by implementation and observation to identify areas of improvement for steady adjustment.

Reference:

readings icon

Service Design

Please read pp. 61 - 66. Pay close attention to the discussion of the design of microservices components and the sizing of these microservices especially when it comes to avoiding sharing data across services, which is not ideal. A primary concern is the avoidance on non-essential complexity. Much of how these decisions relates to specific, detailed elements of the system. In this short reading you are introduced to the concepts of microservices boundaries and domain-driven design which rely on the decomposition of existing services into smaller discrete parts where the domain drives the boundaries of the system. This leads to the concept of using bounded contexts to aid in the identification of smaller components which are compatible with sems that indicate where the boundaries may logically occur for microservices.

Reference:

Additional Learning Resources

readings icon

Netflix to hand infrastructure heavy lifting to AWS

This article discusses how Netflix has moved from hosting their own data centres into an AWS environment to focus on their core service. It details how they will be moving to focus their efforts on microservices with over 500 microservices that will allow teams to iterate faster through continuous deployment with a more agile approach.

Reference:

Barbaschow, A. (2016, December 1). Netflix to hand infrastructure heavy lifting to AWS. ZDNet. Retrieved from https://www.zdnet.com/article/netflix-to-hand-infrastructure-heavy-lifting-to-aws/

Splitting the monolith

Introduction:

As monoliths grow over time, they can become large and unwieldy – and this can materially slow down development cycles and prevent an organisation from being competitive as it stalls in bringing new capability to market. It is recognised that a microservices architecture allows an organisation to be nimbler however untangling the monolith is also understood to be a task that requires deliberate design, clear systems thinking and patient ‘untangling’. Newman (2015) outlines several different tactics that can be used to isolate services which can be teased out from the monolith though the identification of seams, bounded contexts and transactions. It is well recognised that this migration is an epic journey as decisions are taken about which capability to decouple first and how to progressively migrate services from the monolith. This clearly is a complex decomposition task, which depends on decoupling the correct services. This requires an examination of the current code base to determine what seams exist that may make for logical boundaries to services that can be isolated. However, this is not the only criteria to be considered – team capability is also an important decisions point (we will discuss this further in Module 3). Pay attention to both the tools that Newman offers, as well as the four reasons that he gives as to why it makes sense to split the monolith despite the challenges inherent in decomposition of the existing monolith and the required refactoring. Pay close attention to the challenges identified by McKendrick (2019) – while it is clear that there are very many benefits to moving from monoliths to microservices architecture, this is not a simple process and needs to be undertaken with care and deliberation with every effort to be taken to mitigate the challenges.

References

1. Newman, S. (2015). Building microservices: Designing fine-grained systems. California, USA: O’Reilly Media. Retrieved from https://ebookcentral-proquest-com.ezproxy.laureate.net.au/lib/think/reader.action?docID=1938300

2. McKendrick, J. (2019, March 8). They say that breaking up monolithic systems is hard to do. ZDNet. Retrieved from https://www.zdnet.com/article/they-say-that-breaking-up-monolithic-systems-is-hard-to-do/

Resources and Activities:

video icon

Splitting the monolith

Please watch the following video from the DevOps foundations: Microservices series:

1. 4.Microservices by examples: Splitting the monolith (3m 47s)

In this short video clip, the presenter walks you through a practice-based example of how a team analysed a monolith to find new ways to structure future microservices. Please note how they not only looked at the existing code base to isolate seams of code that could be treated in isolation, but also paid attention to bounded contexts to identify service boundaries and also team capability in arriving at logical splits.

Reference:

Stone, L. (2019, February 27). Microservices by examples: Splitting the monolith. [Video file]. Retrieved from https://www.linkedin.com/learning-login/share?forceAccount=false&redirect=https%3A%2F%2Fwww.linkedin.com%2Flearning%2Fdevops-foundations-microservices%3Ftrk%3Dshare_ent_url&account=56744473

readings icon

Splitting the monolith

Please read pp. 79 – 80. Decomposing a monolith is a challenging process – and in this reading Newman offer tools and perspectives about how this can be done successfully. Pay close attention to how Newman identifies the concept of ‘seams’ and how this relates to the concept of a ‘bounded contexts’ and how these offer a means to identify service boundaries.

Reference:

readings icon

Reasons to split the monolith

Please read pp. 81 –82. In this section, Newman outlines four reasons to split the monolith: pace of change, team structure, security and technology. He makes important notes about how these reasons for splitting the monolith may in fact be guiding principles in how the monolith should be decomposed.

Reference:

readings icon

Tangled dependencies

Please read pp. 82 -88. After identifying bounded contexts, seams – tangled dependencies still present challenges. Pay close attention to how Newman recommends developing an understanding of the problem (Getting to Grips), and how breaks can be staged to allow for services to be further decomposed into autonomous parts. Also, pay close attention to his description of transactional boundaries and how these may impact on how services may be decomposed.

Reference:

readings icon

They say that breaking up monolithic systems is hard to do

This article gives practical and industry-based insights into how challenging the process of splitting the monolith can be and how the complexity of the process requires careful and specific management of the transition process.

Reference:

McKendrick, J. (2019, March 8). They say that breaking up monolithic systems is hard to do. ZDNet. Retrieved from https://www.zdnet.com/article/they-say-that-breaking-up-monolithic-systems-is-hard-to-do/

Additional Learning Resources

readings icon

The next generation of Health IT

This article gives insight into the value that microservices architecture can offer within the context of Health IT systems. The aim is to ground your understanding within a practice-based context.

Reference:

Nichol, P.B. (20017, February). Monolithic vs. microservices architectures for innovation. CIO. Retrieved from https://www.cio.com/article/3163169/monolithic-vs-microservice-architectures-for-innovation.html