What is serverless computing?

The promise of serverless computing

What if you could spend all your time building and deploying great apps, and none of your time managing servers? Serverless computing lets you do just that because the infrastructure you need to run and scale your apps is managed for you. Focus your efforts on your business. Redirect resources from infrastructure management into innovating and bringing apps to market faster.

What is serverless computing?

Serverless computing is the abstraction of servers, infrastructure, and operating systems. When you build serverless apps you don’t need to provision and manage any servers, so you can take your mind off infrastructure concerns. Serverless computing is driven by the reaction to events and triggers happening in near-real-time—in the cloud. As a fully managed service, server management and capacity planning are invisible to the developer and billing is based just on resources consumed or the actual time your code is running.

Why build serverless applications?

Benefit from fully managed services

Spare your teams the burden of managing servers. By utilizing fully managed services, you focus on your business logic and avoid administrative tasks. With serverless architecture you simply deploy your code, and it runs with high availability.

Scale flexibly

Serverless compute scales from nothing to handle tens of thousands of concurrent functions almost instantly (within seconds), to match any workload, and without requiring scale configuration—it reacts to events and triggers in near-real time.

Only pay for resources you use

With serverless architecture, you only pay for the time your code is running. Serverless computing is event-driven, and resources are allocated as soon as they’re triggered by an event. You’re only charged for the time and resources it takes to execute your code—through sub-second billing.

x

EAI Questions

Core Enterprise Architecture 
1. What is Enterprise Architecture? 

2. Typically, what stakeholders would be involved in the Enterprise Architecture lifecycle? 

3. What is an architectural pattern? 

4. How do you manage changes to the Enterprise Architecture in 
a turbulent environment? 

5. What recent technology trends are important to Enterprise Architecture? 

6. What are the most important artifacts of an Enterprise Architecture? 

7. Walk me through a time when you led Enterprise change. 

8. What personal qualities make for a good Enterprise Architect? 

9. How do you sell the benefits of SOA to executives? 

10. How does Enterprise Architecture support business goals and strategy? 

11. How can you tell if an Enterprise Architecture is comprehensive? 

12. Is it possible to calculate ROI for SOA? 

13. How do you go about identifying the key business activities in an organization’s value-chain? 

14. Can you give an example where you created a architectural roadmap? How did you align project solutions with the roadmap? 

15. Can you give an example where you championed a project? How did you justify the project to the business? 

16. What was the most complex project in which you assumed a leadership role? What challenges did you face? 

17. How would you go about appraising an Enterprise Architecture in terms of completeness of scope? 

18. What metrics can be used to validate conformance of a solution to an architecture? 

19. Can you give an example where you helped establish a IT governance process? 

20. Can you provide an example in which you provided break-through architectural thinking? 

21. Can you give an example where you applied strategic architectural thinking to impact business results? 

22. Can you give an example where you championed a business stakeholders’ requirements? 

23. Is it possible to calculate ROI for Enterprise Architecture? 

24. Can you give an example in which you evangelized architectures and strategies to executives? 

25. Can you give me an example in which you allocated architectural activities to multiple architects? 

26. Can you give an example where you guided an organization’s strategy? 

27. Can you give an example where you pointed out weak links in technical plans? 

28. Can you give an example where you drove a business initiative by promoting cross-organizational participation? 

29. Can you provide examples where you applied different data modeling techniques for different purposes? 

30. Can you provide me an example where you proposed a solution that satisfied business requirements? What architectural alternatives did you consider? 

31. Have you ever introduced a new standard into an organization? What was it? How did you ensure adoption of the standard? 

32. Give me an example where someone challenged your architectural decisions. 

33. What was the most difficult architectural question anyone ever asked you? How did you answer it? 

34. Give me an example where you defined and executed a strategy. 

35. What IT industry trends are you most interested in at the moment? 

36. How do you maintain your skills and stay current with IT trends? 

37. Have you ever helped to mediate opposing architectural viewpoints? 

38. What tools have you used to create and manage Architectural artifacts? 

39. Can you describe a situation where a key decision you made was wrong? How did you correct the situation? 

40. Can you describe a document you created that demonstrated your ability to effectively communicate architectural decisions? Did the document generate two-way communication? 

Enterprise Architecture Frameworks 
41. What is your favorite Enterprise Architecture framework? Why? 

42. Do you have experience with any TOGAF Certified Tools? 

43. What four architecture domains does TOGAF deal with? 

44. What is the TOGAF Enterprise Continuum? 

45. Can you describe the TOGAF Architecture Compliance Review Process? 

SOA Architecture 
46. Can you give me a recent example of your SOA projects? How did you handle security? 

47. What is a SOA service contract and why is it important? 

48. What is the difference between services and components? 

49. What SOA design patterns have you used in the past? 

50. What design principles do you use when architecting SOA services? 

51. How can you achieve loose coupling of services? 

52. How do you define a successful SOA? 

53. What works better top-down or bottom-up service identification? 

54. How can services supporting long running processes be scaled effectively? 

55. How can a SOA avoid redundant service logic? 

Methodologies 
56. What is the difference between agile and scrum? 

57. Give me an example where you worked with stakeholders to document functional and non-functional requirements. How did you prioritize the requirements? 

58. Can you give an example where you worked with a project manager to identify elements of a project plan that put the project plan at risk? 

59. What is a project communication plan? 

60. What is a project charter? What essential elements should be captured in a project charter? 

IT service management 
61. How would you migrate a traditional application to cloud infrastructure? 

62. How might IT service management processes differ between a small-scale and large-scale enterprise? 

63. Can you give an example where you prepared a Risk Assessment for IT Services? 

64. Can you name 3 kinds of SLA? 

65. What is Network Policy Enforcement? 

66. What is a Operational Level Agreement? 

67. What is ITIL? 

68. What is the difference between Incident Management and Problem Management? 

69. What is the difference between Change and Release management? 

70. What are the key activities associated with Capacity Management? 

Security 
71. What is Cross Site Scripting? 

72. Can you give me an architectural overview of public-key cryptography? 

73. From a security perspective, what is more important to focus on: threats or vulnerabilities? 

74. What is the goal of enterprise information security? 

75. What is Federated Identity Management? 

Solution Architecture 
80. What innovative solutions have you created? 

81. How do you version a service inventory? 

82. If you had to both compress and encrypt data for transmission, which would you do first? Why? 

83. Can you explain the bridge pattern? 

84. What is a design pattern? 

85. What is the difference between Object Oriented and Aspect Oriented design? 

86. In Java, when should you use an interface and when an abstract class? 

87. What is the difference between an Abstract Factory and a Factory? (Design Patterns) 

88. What is a UML deployment diagram? 

89. What factors impact project success? 

90. Can you describe the role of a solution architect during the different phases of the SDLC? 

General 
91. Are you a Big Picture thinker? Can you give me an example? 

92. What do you know about our company? 

93. What do you do to build and manage your professional network? 

94. Have you ever worked within an organization that has a siloed structure? How did you deal with it? 

95. What was the best project you ever worked on? How did you contribute? 

96. How do you deal with difficult people? 

97. What are the three tools you need most to do your job? 

98. Can you describe your leadership style? 

99. Have you ever mentored someone? 

100. Where do you see your career 5 years from now? 

101. What is your experience in the area of IT financial management? 

https://simplicable.com/new/top

Application Program Interfaces - API

Application Program Interfaces (APIs)

APIs/information hiding allow for the creation of a minimal interface that is relatively stable that can be used by other software systems to access or manipulate the underlying systems or data. This allows for enhancements to the underlying systems or data without disturbing the software systems that use the API.

Why we need to split monolith app into microservices

Why?

1) Scale independently.


2) Different tech stacks, versions
   

3)  When two are more clients wants to use the same service.


4) Conflicting dependencies.

Distributed cloud apps architecture

Feature                 Past                                  Present

Clients             Enterprise/Intranet              Public/Internet
Demand           Stable(Small)                      Dynamic (Small -> Massive)
Datacenter       Single tenant                       Multi - tenant(noisy neighbor)
Operations       People(expensive)              Automation (cheap)
Scale                Up via few reliable             Out via lots of (Cheap) commodity PCs
                         (expensive) PCs             
Failure             Unlikely but possible          Very likely
Machine loss    Catastrophic                       Normal (no big deal)


Exceptions            Catch, swallow & keep running      Crash & restart
Communication    In order exactly once                       Out of order Clients must retry &
                                                                                       servers must be idempotent.


Failure Model Analysis (FMA)

How will the application detect this type of failure?
How will the application response to his type of failure?
How will you log and monitor this type of failure?

Design self healing apps:

Detect failures, response to failures gracefully and log and monitor failures to give operational insight


Recommendations:

1) Retry failed operations. Transient failures might occur due to momentary loss of network connectivity, a dropped database connection, or a timeout when a service is busy. Build retry logic into your application to handle transient failures.


2) Protect failing remote services (circuit breaker design pattern). It's advisable to retry after a transient failure, but if the failure persists, you can end up with too many callers hitting a failing service. This can lead to cascading failures as requests back up. Use the circuit breaker design pattern to fail fast (without making the remote call) when an operation is likely to fail.

3) Isolate critical resources (bulkhead pattern). Failures in one subsystem can sometimes cascade. This can happen if a failure causes some resources, such as threads or sockets, from being freed in a timely manner, leading to resource exhaustion. To avoid this, partition a system into isolated groups, so that a failure in one partition does not bring down the entire system.

4) Perform load leveling. Applications may experience sudden spikes in traffic that can overwhelm services on the backend. To avoid this, use the queue-based load leveling pattern to queue work items to run asynchronously. The queue acts as a buffer that evens out peaks in the load.

5) Fail over. If an instance can't be reached, fail over to another instance. For things that are stateless, like a web server, put several instances behind a load balancer or traffic manager. For things that store state, like a database, use replicas and fail over. Depending on the data store and how it replicates, this might require the application to deal with eventual consistency.

6) Compensate for failed transactions. In general, avoid distributed transactions because they require coordination across services and resources. Instead, use compensating transactions to undo any step that already completed.
7)Use checkpoints on long-running transactions. Checkpoints can provide resiliency if a long-running operation fails. When the operation restarts (for example, it is picked up by another virtual machine), it can be resumed from the last checkpoint.

8) Degrade gracefully. Sometimes you can't work around a problem, but you can provide reduced functionality that is still useful. Consider an application that shows a catalog of books. If the application can't retrieve the thumbnail image for the cover, it might show a placeholder image. Entire subsystems might be noncritical for the application. For example, in an e-commerce site, showing product recommendations is probably less critical than processing orders.

9)Throttle clients. Sometimes a small number of users create excessive load, which can reduce your application's availability for other users. In this situation, throttle the client for a certain period of time. See the throttling pattern for more information.

10) Block bad actors. Just because you throttle a client, it doesn't mean the client was acting maliciously. It just means that the client exceeded its service quota. But if a client consistently exceeds their quota or otherwise behaves badly, you might block them. Define an out-of-band process for the user to request getting unblocked.

11) Use leader election. When you need to coordinate a task, use leader election to select a coordinator. That way, the coordinator is not a single point of failure. If the coordinator fails, a new one is selected. Rather than implement a leader election algorithm from scratch, consider an off-the-shelf solution such as Apache ZooKeeper.

12) Test with fault injection. All too often, the success path is well tested but not the failure path. A system could run in production for a long time before a failure path is exercised. Use fault injection to test the resiliency of the system to failures, either by triggering actual failures or by simulating them.

13) Embrace chaos engineering. Chaos engineering extends the notion of fault injection by randomly injecting failures or abnormal conditions into production instances.

UML and Architecture Patterns.

UML - Unified Modeling Language.

1) Kruchen's 4 + 1 Model.

2) LucidChart's

3) Component Diagrams

4) Class Diagrams

5) Activity Diagrams

6) Deployment Diagrams

7) Use Case Diagrams.


Architecture Patterns.

1) Multi Tiered architecture.

2) Client Server Architecture

3) Model- View- Controller Architecture

4) Service Oriented Architecture

5) Microservices Architecture

6) Domain Driven Architecture

7) Event Driven Architecture

Asynchronous, Synchronous, Multi threading, Concurrency

Synchronous Programming model – In this programming model, A thread is assigned to one task and starts working on it. Once the task completes then it is available for the next task. In this model, it cannot leave the executing task in mid to take up another task. Let’s discuss how this model works in single and multi-threaded environments.

Single Threaded – If we have couple of tasks to be worked on and the current system provides just a single thread, then tasks are assigned to the thread one by one. It can be pictorially depicted as

Here we can see that we have a thread (Thread 1 ) and four tasks to be completed. Thread starts workingon the tasks one by one and completes all. (The order in which tasks will be taken up, does not affect the execution, we can have different algorithm which can define the priorities of tasks)

Multi-Threaded – In this environment, we used to have multiple threads which can take up these tasks and start working on that. It means we have a pool of threads (new threads can also be created based on the requirement and available resources) and bunch of tasks. So these thread can work on these as

Here we can see that we have four threads and same number of tasks to complete. So each thread takes up one task and completes that. This is an ideal scenario but in normal cases, we used to have more number of tasks than the number of available threads. So, whichever thread gets free, takes up another task. As already mentioned that spawning new thread is not an option each time because it requires system resources like CPU, memory.

Now, Let’s talk about Asynchronous model and how does it behave in single and multi-threaded environment.

Asynchronous Programming Model – In contrary to Synchronous programming model, here a thread once start executing a task it can hold it in mid, save the current state and start executing another task.

Here we can see that a single thread is responsible to complete all the tasks and tasks are interleaved to each other.

If our system is capable of having multiple threads then all the threads can work in asynchronous model as well

Here we can see that same task say T4, T5, T6.. are handled by multiple thread. This is the beauty of this scenario. As you can see that T4 was started first in Thread 1 and completed by Thread 2. Similarly, T6 is completed by Thread 2, Thread 3 and Thread 4. It shows the maximum utilization of the threads.

So till now we have discussed four scenarios –

1. Synchronous Single Threaded
2. Synchronous Multi-Threaded
3. Asynchronous Single Threaded
4. Asynchronous Multi-Threaded

Let’s discuss one more term – Concurrency.

Concurrency

In simple terms, concurrency means processing multiple requests at a time. As we have discussed two scenarios where multiple requests were getting processed, Multi-threaded programming and asynchronous model (single and multi-threaded both). In case of asynchronous model whether single or multi-threaded, multiple tasks are in progress at a time, some are in hold state and some are getting executed. There are many flavors of it but that is beyond the scope of this post.

As discussed earlier, the new age is of asynchronous programming. Why is it so important?

Benefits of Asynchronous Programming

There are two things which are very important for any application – Usability and Performance. Usability because say a user clicks on a button to save some data. This requires multiple smaller tasks like reading and populating data in internal object, establishing connection with SQL and saving it there etc. As SQL runs on another machine in network and runs under different process, it could be time consuming and may take bit longer. So, if the application runs on a single thread then the screen will be in hanged state till all the tasks completes which is a very bad user experience. That’s why nowadays many applications and new frameworks completely rely on asynchronous model.

Performance of an application is also very important. It has been seen that while executing a request, around 70-80% of the time gets wasted while waiting for the dependent tasks. So, it can be maximum utilized by asynchronous programming where once the task is passed to another process (say SQL), current thread saves the state and available to take another task. When the SQL task completes any thread which is free, can take it up further.

Asynchrony in ASP.NET

Async in ASP.NET can be a major boost in the throughput of your application. Let’s see, how IIS processes a request.

When a request is received by IIS, it takes a thread from CLR thread pool (IIS does not own any thread-pool itself instead uses CLR thread pool) and assigns to it which further processes the request. As number of threads are limited and new ones can be created at a certain limit then if the thread wastes most of the time in waiting then it’s going to hit hard to your application’s overall performance. But if you write asynchronous code (which now become very easy and can be written almost similar to synchronous using the new keywords async/await in C#) then it will be way faster and throughput of your server will increase significantly because instead of waiting something to complete, it will be available to thread pool to take the new requests. If the application has a lot of dependency and long running process then for those application, async programming will be not less than a boon.

SOA vs MSA vs CNA

Monolithic vs Microserivce Architecture

Monolithic Architecture

Context

You are developing a server-side enterprise application. It must support a variety of different clients including desktop browsers, mobile browsers and native mobile applications. The application might also expose an API for 3rd parties to consume. It might also integrate with other applications via either web services or a message broker. The application handles requests (HTTP requests and messages) by executing business logic; accessing a database; exchanging messages with other systems; and returning a HTML/JSON/XML response. There are logical components corresponding to different functional areas of the application.

Problem

What’s the application’s deployment architecture?

Forces

• There is a team of developers working on the application
• New team members must quickly become productive
• The application must be easy to understand and modify
• You want to practice continuous deployment of the application
• You must run multiple copies of the application on multiple machines in order to satisfy scalability and availability requirements
• You want to take advantage of emerging technologies (frameworks, programming languages, etc)

Solution

Build an application with a monolithic architecture. For example:

• a single Java WAR file.
• a single directory hierarchy of Rails or NodeJS code

Example

Let’s imagine that you are building an e-commerce application that takes orders from customers, verifies inventory and available credit, and ships them. The application consists of several components including the StoreFrontUI, which implements the user interface, along with some backend services for checking credit, maintaining inventory and shipping orders.

The application is deployed as a single monolithic application. For example, a Java web application consists of a single WAR file that runs on a web container such as Tomcat. A Rails application consists of a single directory hierarchy deployed using either, for example, Phusion Passenger on Apache/Nginx or JRuby on Tomcat. You can run multiple instances of the application behind a load balancer in order to scale and improve availability.

Resulting context

This solution has a number of benefits:

• Simple to develop - the goal of current development tools and IDEs is to support the development of monolithic applications
• Simple to deploy - you simply need to deploy the WAR file (or directory hierarchy) on the appropriate runtime
• Simple to scale - you can scale the application by running multiple copies of the application behind a load balancer

However, once the application becomes large and the team grows in size, this approach has a number of drawbacks that become increasingly significant:

• The large monolithic code base intimidates developers, especially ones who are new to the team. The application can be difficult to understand and modify. As a result, development typically slows down. Also, because there are not hard module boundaries, modularity breaks down over time. Moreover, because it can be difficult to understand how to correctly implement a change the quality of the code declines over time. It’s a downwards spiral.
• Overloaded IDE - the larger the code base the slower the IDE and the less productive developers are.
• Overloaded web container - the larger the application the longer it takes to start up. This had have a huge impact on developer productivity because of time wasted waiting for the container to start. It also impacts deployment too.
• Continuous deployment is difficult - a large monolithic application is also an obstacle to frequent deployments. In order to update one component you have to redeploy the entire application. This will interrupt background tasks (e.g. Quartz jobs in a Java application), regardless of whether they are impacted by the change, and possibly cause problems. There is also the chance that components that haven’t been updated will fail to start correctly. As a result, the risk associated with redeployment increases, which discourages frequent updates. This is especially a problem for user interface developers, since they usually need to iterative rapidly and redeploy frequently.
• Scaling the application can be difficult - a monolithic architecture is that it can only scale in one dimension. On the one hand, it can scale with an increasing transaction volume by running more copies of the application. Some clouds can even adjust the number of instances dynamically based on load. But on the other hand, this architecture can’t scale with an increasing data volume. Each copy of application instance will access all of the data, which makes caching less effective and increases memory consumption and I/O traffic. Also, different application components have different resource requirements - one might be CPU intensive while another might memory intensive. With a monolithic architecture we cannot scale each component independently
• Obstacle to scaling development - A monolithic application is also an obstacle to scaling development. Once the application gets to a certain size its useful to divide up the engineering organization into teams that focus on specific functional areas. For example, we might want to have the UI team, accounting team, inventory team, etc. The trouble with a monolithic application is that it prevents the teams from working independently. The teams must coordinate their development efforts and redeployments. It is much more difficult for a team to make a change and update production.
• Requires a long-term commitment to a technology stack - a monolithic architecture forces you to be married to the technology stack (and in some cases, to a particular version of that technology) you chose at the start of development . With a monolithic application, can be difficult to incrementally adopt a newer technology. For example, let’s imagine that you chose the JVM. You have some language choices since as well as Java you can use other JVM languages that inter-operate nicely with Java such as Groovy and Scala. But components written in non-JVM languages do not have a place within your monolithic architecture. Also, if your application uses a platform framework that subsequently becomes obsolete then it can be challenging to incrementally migrate the application to a newer and better framework. It’s possible that in order to adopt a newer platform framework you have to rewrite the entire application, which is a risky undertaking.

Microservice Architecture

Context

You are developing a server-side enterprise application. It must support a variety of different clients including desktop browsers, mobile browsers and native mobile applications. The application might also expose an API for 3rd parties to consume. It might also integrate with other applications via either web services or a message broker. The application handles requests (HTTP requests and messages) by executing business logic; accessing a database; exchanging messages with other systems; and returning a HTML/JSON/XML response. There are logical components corresponding to different functional areas of the application.

Problem

What’s the application’s deployment architecture?

Forces

• There is a team of developers working on the application
• New team members must quickly become productive
• The application must be easy to understand and modify
• You want to practice continuous deployment of the application
• You must run multiple copies of the application on multiple machines in order to satisfy scalability and availability requirements
• You want to take advantage of emerging technologies (frameworks, programming languages, etc)

Solution

Define an architecture that structures the application as a set of loosely coupled, collaborating services. This approach corresponds to the Y-axis of the Scale Cube. Each service implements a set of narrowly, related functions. For example, an application might consist of services such as the order management service, the customer management service etc.

Services communicate using either synchronous protocols such as HTTP/REST or asynchronous protocols such as AMQP. Services can be developed and deployed independently of one another. Each service has its own database in order to be decoupled from other services. Data consistency between services is maintained using the Saga pattern

Examples

Fictitious e-commerce application

Let’s imagine that you are building an e-commerce application that takes orders from customers, verifies inventory and available credit, and ships them. The application consists of several components including the StoreFrontUI, which implements the user interface, along with some backend services for checking credit, maintaining inventory and shipping orders. The application consists of a set of services.

Show me the code

Please see the example applications developed by Chris Richardson. These examples on github.com illustrate various aspects of the microservice architecture.

Resulting context

Benefits

This solution has a number of benefits:

• Enables the continuous delivery and deployment of large, complex applications.
  • Better testability - services are smaller and faster to test
  • Better deployability - services can be deployed independently
  • It enables you to organize the development effort around multiple, auto teams. It enables you to organize the development effort around multiple teams. Each (two pizza) team is owns and is responsible for one or more single service. Each team can develop, deploy and scale their services independently of all of the other teams.
• Each microservice is relatively small
  • Easier for a developer to understand
  • The IDE is faster making developers more productive
  • The application starts faster, which makes developers more productive, and speeds up deployments
• Improved fault isolation. For example, if there is a memory leak in one service then only that service will be affected. The other services will continue to handle requests. In comparison, one misbehaving component of a monolithic architecture can bring down the entire system.
• Eliminates any long-term commitment to a technology stack. When developing a new service you can pick a new technology stack. Similarly, when making major changes to an existing service you can rewrite it using a new technology stack.

Drawbacks

This solution has a number of drawbacks:

• Developers must deal with the additional complexity of creating a distributed system.
  • Developer tools/IDEs are oriented on building monolithic applications and don’t provide explicit support for developing distributed applications.
  • Testing is more difficult
  • Developers must implement the inter-service communication mechanism.
  • Implementing use cases that span multiple services without using distributed transactions is difficult
  • Implementing use cases that span multiple services requires careful coordination between the teams
• Deployment complexity. In production, there is also the operational complexity of deploying and managing a system comprised of many different service types.
• Increased memory consumption. The microservice architecture replaces N monolithic application instances with NxM services instances. If each service runs in its own JVM (or equivalent), which is usually necessary to isolate the instances, then there is the overhead of M times as many JVM runtimes. Moreover, if each service runs on its own VM (e.g. EC2 instance), as is the case at Netflix, the overhead is even higher.

Issues

There are many issues that you must address.

When to use the microservice architecture?

One challenge with using this approach is deciding when it makes sense to use it. When developing the first version of an application, you often do not have the problems that this approach solves. Moreover, using an elaborate, distributed architecture will slow down development. This can be a major problem for startups whose biggest challenge is often how to rapidly evolve the business model and accompanying application. Using Y-axis splits might make it much more difficult to iterate rapidly. Later on, however, when the challenge is how to scale and you need to use functional decomposition, the tangled dependencies might make it difficult to decompose your monolithic application into a set of services.

How to decompose the application into services?

Another challenge is deciding how to partition the system into microservices. This is very much an art, but there are a number of strategies that can help:

• Decompose by business capability and define services corresponding to business capabilities.
• Decompose by domain-driven design subdomain.
• Decompose by verb or use case and define services that are responsible for particular actions. e.g. a Shipping Service that’s responsible for shipping complete orders.
• Decompose by by nouns or resources by defining a service that is responsible for all operations on entities/resources of a given type. e.g. anAccount Service that is responsible for managing user accounts.

Ideally, each service should have only a small set of responsibilities. (Uncle) Bob Martin talks about designing classes using the Single Responsibility Principle (SRP). The SRP defines a responsibility of a class as a reason to change, and states that a class should only have one reason to change. It make sense to apply the SRP to service design as well.

Another analogy that helps with service design is the design of Unix utilities. Unix provides a large number of utilities such as grep, cat and find. Each utility does exactly one thing, often exceptionally well, and can be combined with other utilities using a shell script to perform complex tasks.

How to maintain data consistency?

In order to ensure loose coupling, each service has its own database. Maintaining data consistency between services is a challenge because 2 phase-commit/distributed transactions is not an option for many applications. An application must instead use the Saga pattern. A service publishes an event when its data changes. Other services consume that event and update their data. There are several ways of reliably updating data and publishing events including Event Sourcing and Transaction Log Tailing.

How to implement queries?

Another challenge is implementing queries that need to retrieve data owned by multiple services.

• The API Composition and Command Query Responsibility Segregation (CQRS) patterns.

Related patterns

There are many patterns related to the microservices pattern. The Monolithic architecture is an alternative to the microservice architecture. The other patterns address issues that you will encounter when applying the microservice architecture.

• Decomposition patterns
  • Decompose by business capability
  • Decompose by subdomain
• The Database per Service pattern describes how each service has its own database in order to ensure loose coupling.
• The API Gateway pattern defines how clients access the services in a microservice architecture.
• The Client-side Discovery and Server-side Discovery patterns are used to route requests for a client to an available service instance in a microservice architecture.
• The Messaging and Remote Procedure Invocation patterns are two different ways that services can communicate.
• The Single Service per Host and Multiple Services per Host patterns are two different deployment strategies.
• Cross-cutting concerns patterns: Microservice chassis pattern and Externalized configuration
• Testing patterns: Service Component Test and Service Integration Contract Test
• Circuit Breaker
• Access Token
• Observability patterns:
  • Log aggregation
  • Application metrics
  • Audit logging
  • Distributed tracing
  • Exception tracking
  • Health check API
  • Log deployments and changes
• UI patterns:
  • Server-side page fragment composition
  • Client-side UI composition

Known uses

Most large scale web sites including Netflix, Amazon and eBay have evolved from a monolithic architecture to a microservice architecture.

Netflix, which is a very popular video streaming service that’s responsible for up to 30% of Internet traffic, has a large scale, service-oriented architecture. They handle over a billion calls per day to their video streaming API from over 800 different kinds of devices. Each API call fans out to an average of six calls to backend services.

Amazon.com originally had a two-tier architecture. In order to scale they migrated to a service-oriented architecture consisting of hundreds of backend services. Several applications call these services including the applications that implement the Amazon.com website and the web service API. The Amazon.com website application calls 100-150 services to get the data that used to build a web page.

The auction site ebay.com also evolved from a monolithic architecture to a service-oriented architecture. The application tier consists of multiple independent applications. Each application implements the business logic for a specific function area such as buying or selling. Each application uses X-axis splits and some applications such as search use Z-axis splits. Ebay.com also applies a combination of X-, Y- and Z-style scaling to the database tier.

There are numerous other examples of companies using the microservice architecture.

Source of this content: https://microservices.io/patterns/index.html , it's a good read to refresh your architecture skills.