This chapter is from the book
This chapter is from the book
This chapter is from the book
Flak.io e-Commerce Sample
Flak.io is an open-source microservices sample application used for demonstrating microservices concepts and exploring related technologies. In this section we will walk through the sample application design and considerations. The application is small and simple, designed to provide us with enough examples to cover many of the concepts discussed through this book.
Flak.io is an ecommerce application that enables shoppers to browse and purchase products from a catalog. Let’s start with a look at some of the flak.io requirements.
Flak.io
Flak.io is an advanced technology reseller that sells unique products online for the modern-day space explorers. Space exploration is growing fast, and the demand for equipment is rapidly growing with it. Flak.io needs to release an ecommerce solution that can scale to handle the expected demands. The online retail market for space exploration equipment is getting very competitive, and flak.io must remain agile and capable of continuous innovation. Flak.io has decided to build their new storefront technology using microservices architecture. The team has some high-level requirements that align well with the benefits of a microservices architecture.
Initially users will simply need to be able to browse a catalog of products and purchase them online. Initially users will not need to log in or create accounts, but eventually this feature will be added. The catalog will include basic browse and search capabilities, enabling a user to find a product by entering search terms and browsing products by category. When viewing products on the site, the user will be displayed a list of related and recommended products based on the analysis of past orders and browsing histories. The user will add products that he or she wishes to purchase to a shopping cart and then make the purchase. The user will then receive an email notification with a receipt and details of the purchase.
Requirements
Continuous Innovation: To keep their positon in the market, the flak.io team needs to be able to experiment with new features and release them into the market immediately.
Reduce Mean Time to Recovery (MTTR): The DevOps team needs to be able to quickly identify and release fixes to the service.
Technology Choice: New technologies are constantly being introduced into the market that can be leveraged in key areas of the application, and it’s important that the team is able to quickly adopt them if it makes sense for the business.
Optimize resources: It’s important that the application is optimized to reduce cloud infrastructure costs.
Application availability: It’s important that some features of the application are highly available.
Reduce developer ramp-up: The team has been growing quickly, and it’s important that new developers are able to ramp up and begin contributing immediately.
It’s apparent the Flak.io ecommerce application will benefit from a microservices architecture and the costs are worth the return. The team has enough experience in DevOps to service design to handle it, and the application has been decomposed into the following set of services.
Architecture Overview
As we see in Figure 3.2, the application is decomposed into four services.
)
Figure 3.2: Flak.io architecture overview diagram
The catalog service contains categories and product information, and images.
The order service is responsible for processing orders. You should note that the order service would also have a product model that’s different from that in the catalog service, because it belongs to a different context.
The recommendation service is responsible for analyzing historical information and possibly more real time information to make recommendations.
The notification service is responsible for sending email notifications, as well as storing and managing email templates.
The application uses a mix of synchronous and asynchronous messaging techniques. The application will be deployed into a cluster using cluster management and orchestration tooling, which will be discussed in more detail in Chapter 5.
Considerations
Some things to consider when decomposing an application into individual services:
Right now the client makes one request to retrieve catalog information and another for recommendations. We might want to reduce chattiness in the client and aggregate the request in the proxy or make one of the services responsible for that. For example, we can send a request to the catalog service which could request recommendations from the recommendation service, or have the edge proxy fan out and call both and return the combined result.
We might want to further decompose a bounded context around business components, components, or other things. For example, depending on how our application scales, we might want to separate the search function from the other catalog features. We will keep it more coarsely grained until we determine there is a need to further partition.
Elasticsearch is used in place of other graph databases for providing recommendations for a couple of reasons. Elasticsearch includes an extremely powerful graph API, and because it’s used for other areas, we can reduce the number of technologies and share information for best practices.
We could place the recommendations and products into different indexes of the same Elasticsearch cluster. As long as one service is not permitted to directly access the other service’s index, we should be fine and might be able to reduce costs by running multiple clusters.
It’s quite possible that many of these services could be further decomposed into more microservices. For example, the team had considered further decomposing the order service into more services, by moving some of the functionality out to a payment/checkout service. However, the team had determined that refactoring it at a later time would require minimal work, and they were not ready to manage more services or the complexities it involves at this time.
Domain-Driven Design is an approach and a tool. It’s a great tool in this situation, but it’s not the only approach to decomposing a domain into separate services.
At the moment, customers are anonymous and simply enter payment information every time they make a purchase. In the future, a feature will be added to the application that enables customer accounts.