In this first chapter, you will get to know the basics of microservices. They have been an upcoming trend over the last few years and gained popularity particularly amongst start-ups and projects that are built to grow. Their appeal is that they are designed to be scalable but also offer great flexibility to the programmer. By the end of this book, you will be capable of writing your own microservices for apps and frontends using the Swift framework, Vapor. This chapter will give you an overview of what microservices are and how they are useful in web development.
Microservices are small, individual services that form an application by working together. In contrast to that, monoliths are applications that are operating out of one central service that does not depend on other services. Most traditional off-the-shelf systems such as WordPress and Drupal are monoliths.
Both microservices as well as their counterpart, monoliths, are central elements of modern web development and before you start developing your own, you should understand the essential theory for their usage. You will specifically explore the following topics in this chapter:
- What is a microservice?
- Understanding why to choose microservices
- Understanding why not to choose microservices
- Who is using microservices?
- Monolith versus microservices
- Upgrading from monolith to microservices
After reading this chapter, you will be prepared to start working on your microservices.
Let's quickly define what we mean when we use the term microservice.
As the word already gives away, microservice consists of micro and service. Micro is smaller than small. A microservice by definition should be as small as possible. The other word, service, refers to the function of a microservice: it should do something for us. In this book—and in general—we call them microservices, the plural form of microservice. We do that because a microservice usually operates together with other microservices. A microservice application consists of multiple microservices working together and alongside each other.
Almost all major players, such as Google, Amazon, and Facebook, started out as so-called monolithic applications. What does that mean? In essence, a monolith is an application that operates as one large code base. Popular examples include WordPress, Joomla!, Magento, and Drupal; they typically run on one server for the frontend, PHP oftentimes. If you need to scale such an application, you would add more frontend servers that all do the same thing; they are replicas of each other.
While that would solve the demand issue, another problem exists as well: every time the web page is updated, by changing the source code, a single error could bring down the entire web page. The dominant web technologies for so-called monolith web applications used to be primarily PHP and some used to be Java and Perl. Wikipedia, Yahoo!, Facebook, and many others rely on PHP to this very day. Over time, additional scripting languages such as Python and Ruby entered the race. However, the following problem prevailed: changing source files could introduce bugs and bring down the entire site because every PHP file is usually somehow connected to the others. As the companies grew, they adopted another approach, which has proven to be much more reliable for continuous growth and maintainability. The approach, microservices, includes the idea that a web application does not consist of one big monolith anymore but is divided up into many independent services that work together.
The approach itself is not all that new; logistic companies had implemented such a strategy for their structures as well. But growing internet tech companies used this method to solve two of their main problems:
- Scalability: Individual services are much easier to scale than scaling the entire system.
- Maintainability: When changing or adjusting one service, it will not affect the other services, which creates a more solid and stable system overall.
For all of the intents and purposes of this book, let's use the following definition of microservices: a microservice is a small service that runs along with other services and builds the application together with the other services.
There is no actual official definition of what a microservice is and is not; however, the following rules generally apply to commonly used microservices:
- A small unit of a backend infrastructure
- Operating as independently as possible (meaning, no or little communication with other microservices)
- Performing a service (such as processing data or offering an API)
- Offering as little functionality as reasonable
- Operates with its own database
The same applies to common code or libraries; it should always be separate. You might develop a central library that is shared; however, that might become a problem later on. Zalando, for example, implemented a strict policy prohibiting this (https://www.infoq.com/news/2016/02/Monolith-Microservices-Zalando).
To conclude, a microservice is the smallest and most isolated unit possible of the business logic and is needed for the server application. Now, let's look at the cases when microservices are a great choice!
Let's look at some of the reasons why you might want to choose microservices for your applications. Not every application should utilize microservices, as you will see in the next section. Very distinct reasons warrant the use of microservices. Let's take an example to justify why we want to choose microservices.
Let's pretend you want to develop a simple e-commerce app. If we say that there are three different elements of microservices in an app, User, Product, and Order. The app should cover the following features:
- User: Log in
- User: Register
- User: Change addresses
- User: Change payment methods
- Products: Show the list of products in a category
- Products: Show details about an individual product
- Order: Submit an order of products
- Order: Submit payment for an order
You could develop the backend for such an app as a monolith, of course. It would, without a doubt, be a rather big application and require many models and controllers. But if you were to develop the same app with microservices, you could end up with three more flexible packages, such as the following:
- User Manager
- Products Manager
- Order Manager
You can now enjoy the following benefits from using microservices:
- Effective team management
- Reusable code base
- Flexible scope of functionality
- Mixed stacks
Let's dive into each of these sections now.
If you have ever worked in a team on a bigger monolithic application, you know very well how chaotic and unorganized it can get. Various preferences, styles, and trains of thoughts are commonly joined together, resulting in a decently sized mess.
With microservices, you can assign different services to different team members. In the preceding example, if you happen to be a three-member team, each one of you could develop one service. The added efficiency will not just increase productivity in the beginning but carry through the entire project.
Spreading out the workload across multiple people working separately but still together is a significant benefit for all of the teams. Imagine you have to manage 500+ programmers for a big project (think Facebook or Google). It is close to impossible to function well over a longer period of time if everyone is using the same code base. If the application is split up into small microservices, you can have a lot of 10-people teams that are working on various services. While this comes with its own challenges, it will certainly reduce the potential for error in the code itself.
But even if you happen to be in a small team, few developers can experience a noticeable increase in productivity when developing microservices.
In essence, microservices allow you to spread work out effectively in a team.
For the sake of this discussion, let's assume that you have already written a user manager once before and now you can use it again. With microservices, you can use and reuse any given service that you have developed previously. If a service does not quite fit your case, you could just modify it instead of writing it from scratch.
Reusing the same code across multiple projects saves you valuable time and resources. You may even start thinking about microservices abstractly so that you purposefully can reuse the services. You can try to define a set of functions that fit more than one project for you to reuse with other projects.
Let's take a look at the aforementioned user manager service. Almost all applications that interact with users have a login. In most cases, the functionality is pretty much identical, as shown here:
- Log in via email and password
- Registration with email verification
- Forgot password; send recovery email
- Log out
- Delete account
Once you have written this service you can easily implement it with other projects.
Another similar case is when you are choosing a SaaS solution for user management. Examples include AWS Cognito, Auth0.com, Okta, and Backendless. Microservices allow you to easily incorporate such services to save yourself the time and effort of writing a user management solution at all in this case. Naturally, the same principle applies to other types of services as well.
To summarize, microservices allow you to reuse existing code for new projects and save time and effort. Next, let's explore the scope of functionality.
Imagine you need to add a new payment method to your online shop. In a monolith, you need to work on and deploy the entire application, which comes with risks. However, in microservices, if you have the order manager, you can simply add the payment method to that service and deploy it and you are good to go. The user manager and product manager do not need to be touched.
Microservices allow you to grow your functionality as you need and without needing to touch other parts of the software.
It makes a lot of sense to use microservices not only when your specifications may change, but also in cases where your requirements are highly defined. Microservices are easily maintained; each service can be updated, upgraded, and serviced individually without influencing the other services. This is particularly important with bigger applications as it reduces the risk and impact of potential downtime.
If you are serving a lot of users, you want to avoid downtime as much as possible. Because microservices are independent, you can replace them in time without going offline. You will explore deployments later on in more detail, but most cloud service providers have procedures in place that will keep your application up 100% of the time while switching out the services.
Additionally, you and your team can focus your efforts on the services that need it most. While one service is being heavily updated, the other services can stay the way they were. I have been in a project that had legacy microservices running for over two years because it worked reliably and effort was put into developing new features instead of updating the old ones. You should not neglect updating all parts of your system though, but microservices allow you to keep old infrastructure longer than with a monolith.
In conclusion, microservices allow you to work on them while other services stay as they are and therefore give you the ability to focus on what matters most.
Another element to consider is that you want to be able to grow and scale your application easily. Microservices are arguably the easiest form of application for a server application to grow. Remember, we have individual and independent services running. It means, in principle, that no problem should have the same service run in many instances, for example, you could have 100 servers running the same service. Alternatively, it could also run as only one service, based on your needs.
Let's look into the following three distinct advantages microservices have when it comes to scalability:
- Flexible cost
- Service-oriented availability
You can have your hosting provider automatically scale (up and down) according to your needs. Predefined and customizable rules allow you to define and to scale up and down. If you have an upcoming marketing gig (such as a TV promotion), your backend will automatically scale according to your demand without you having to adjust anything manually.
This goes hand-in-hand with auto-scaling. You may pay for the infrastructure depending on your needs. In an ideal world, you would pay nothing for no users and increasingly more as you have more users. In reality, this rarely happens just like that, however, you do end up saving money as you don't need to buy more hardware than you need in most cases.
Often, not every service is used equally. In the preceding example, the user service only performs authentication and registration. Once the user is authorized, this service is mostly irrelevant to the app. You may decide to have the email processing service to be a lot more available than your user service.
Concretely, this may look like five servers are running the product manager application while only one server runs the user and the order manager. As your app grows and changes, you can adjust this setup precisely to what you need.
So, we can conclude that microservices allow your application to grow effortlessly and you have many options for how you want your entire backend application to run.
Sometimes, you may find yourself in a situation where a part of your tech stack is using other technologies. You may want to write your microservices with Vapor and Swift but have a good bit of infrastructure in PHP. You can utilize microservices to keep some of the old parts while already developing new services. Your setup will then look like the following diagram:
In this case, your user request will be routed either to the (old) PHP monolithic Media & File Management service or to your new Vapor services. Your old monolith is actually turned into a microservice itself, though it most likely covers more functionality than you want it to have. But, deciding to go with microservices allows you to incorporate software that you may depend on even if it is written in an entirely different language.
If you are wondering how the preceding example would look like in real life, most microservices are operating out of containers (for example, Docker containers). These containers operate as mini-servers and are completely isolated. So, even with just one actual hardware server, you can implement the preceding scenario with a local load balancer such as nginx.
Hence, microservices allow you to integrate older parts of your infrastructure while already using your newer parts.
You have seen several reasons to choose microservices. Now, let's look at reasons why not to choose microservices. As with everything, the strengths of microservices are also their weakness. While this book is about writing microservices, you should not think that microservices are the answer to every problem. There are many examples of why microservices are actually the wrong choice for certain problems. Here is a list of some of the reasons why not to choose microservices.
The first and most obvious reason why you would not want to choose microservices is that it is usually a bit more work initially. To set up the entire system and connect the services and get them all up and running the way you need to often requires more work than with a monolithic application.
It starts by setting everything up and building a working environment. A monolithic application will require you to run the application only. So, once you start your main application, you are good to go.
A microservices application, however, requires a setup in which multiple applications are running at the same time. Alternatively, you could design your application to receive test data from static files; this, however, does not replace testing with the actual services. You can archive such a setup easily in a deployment situation; cloud providers are doing an excellent job in helping us here. However, when you start developing, it can be a good amount of work to set everything up. In the next chapter, you will set up your own workspace.
Additionally, microservices demand planning. You cannot perform some changes as quickly as you would in a monolithic application. If you are only building a simple proof-of-concept for your backend, you might be better off starting as a monolith. If you need something implemented that is critical in timing, microservices might not be your best option.
So, a good thing to keep in mind when working with microservices is that microservices demand some planning and often take longer to start.
When developing monolithic applications, you usually have everything in the same code base. As long as a project is small, the lack of complexity makes it easier for you to maintain it. Additional features and changes can be implemented with the same stack, language, and frameworks you have been using so far.
Microservices, on the other hand, can be a bit more complex (or messy even). Adding a new feature is not always trivial and may require changes in numerous services. The services themselves may also have different stacks. You may have a legacy service running PHP combined with a Swift Vapor service for another part of the app. Adding a feature requires you to work in PHP as well as Swift.
If you know your exact scope for a project and don't expect any changes, there is no reason not to implement it like a monolithic application.
Microservices can increase the complexity of a project, compared to traditional technologies such as PHP, which you should keep in mind. The same can be said about most microservice technologies though, regardless of programming language. Let's take a look at troubleshooting and debugging now.
Debugging and troubleshooting is yet another issue you will need to consider. It can be quicker and easier to debug one application as opposed to two or more microservices. Debugging goes hand in hand with complexity; bugs will not be found as quickly as they can be in a monolithic application. As a matter of fact, this topic is important enough for this book to have an entire chapter on it.
If you are dealing with an application that is limited in scope and functionality is not expected to grow, a monolithic approach might be better than a microservice approach. That said, I have personally seen many projects start as "small and manageable" pretty suitable for monolithic applications. But then they grow, and the benefits quickly turn into serious problems. If you think all of your applications should be suitable for growth, take a microservice approach.
It can take more time to find bugs. Because services are often somehow connected, it can be pretty hard to boil a symptom down to a bug. I have seen a small symptom come out of many unrelated errors.
To conclude, debugging a microservice backend is more complex and time-consuming than for monolithic applications, however, there are also great benefits with using them. This is why we will look at a list of companies that are using microservices and have switched away from monoliths.
After learning about the pros and cons of microservices, let's take a look at who is using them. The following examples are not exclusive and were selected with modern web applications in mind. If you want to develop an app that has the potential to become as big as Netflix, why not check out how things work well for them?
It will probably be no surprise to learn that Amazon is one of the first big companies that utilized the internet and implemented microservices. Amazon, like many others, started out by being a big monolithic application. As it grew, additional programmers were hired and started working on the application. As you can imagine, over a hundred developers all working on the same code base will ultimately result in chaos and conflicts. This also happened in the years around 2000; so many modern tools (such as Git) were not nearly as advanced as they are today. Back then, Amazon began to break the big application up into more manageable and usable sub-units, called microservices.
Amazon is now deploying every 11.7 seconds (https://blog.newrelic.com/technology/data-culture-survey-results-faster-deployment/). Despite the challenge of having to enable hundreds of developers to work on the platform, Amazon also solved another problem: growth. Because amazon.com runs as a microservice application, it has no downtime. Amazon can take as many visitors as it gets because the system is managing itself.
By the way, Netflix, Uber, and many others are using Amazon Web Services (AWS). Amazon not only developed the concept and infrastructure for itself but is selling it to others who can use it for the same benefits.
Another noteworthy point is that Jeff Bezos has always advocated for small teams regardless of the size of the company. He claims that a team should not be larger than what two pizzas can feed (http://blog.idonethis.com/two-pizza-team/). As stated earlier, spreading the work out over to multiple people also applies to big corporations: keeping teams small increases efficiency.
Netflix, similar to Amazon, used to be a gigantic monolithic application. And just like Amazon, Netflix split it up into many microservices to accommodate its growth. Now, Netflix is deploying thousands of times a day.
A graphical representation of its API can be found at https://www.slideshare.net/adrianco/netflix-velocity-conference-2011/43-API_AWS_EC2_Front_End
You can see how various components are working together to provide speedy delivery of content. Similar to Amazon, Netflix also had to face challenges in terms of development and growth. Using microservices allows it to address both.
Now, Netflix is serving more than 130 million accounts daily with possibly up to 400 million viewers (https://www.cheatsheet.com/entertainment/how-many-people-use-netflix.html/). These numbers should tell you how powerful a well-designed microservice architecture can be.
The bottom line is Netflix is one of the most frequently visited websites worldwide, and its approaches can teach you how to serve that many people.
Flask with Python was the basis for Uber's monolithic application. Over time, it rewrote its entire logic in smaller Python and Go services. This did not only allow Uber to optimize services according to need but also leverage the ability to use another technology for certain parts of its service. Using Go, Uber was able to increase the performance of its discovery layer.
The process of utilizing microservices well took years for Uber, and Matthew Mengerink said about fully integrating with the cloud:
Note that Uber has many thousands of employees and thousands of developers working on its infrastructure. This example should show you that it can take a long time to incorporate microservices meaningfully, even if you have a lot of engineers.
To conclude, even big companies like Uber need their due time to transition to microservices properly.
Microservices are not limited to big corporations with massive users. As you read in the list of reasons for microservices you can choose microservices even as you are just starting an application. It is often easier to start with the end in mind, rather than settling for the quicker or more expensive option in the long run.
Besides the companies listed previously, the following companies have been known to use microservices as well:
- Comcast Cable: https://qconnewyork.com/ny2015/ny2015/presentation/partial-failures-microservices-jungle-survival-tips-comcast.html
- eBay: http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf
- SoundCloud: https://developers.soundcloud.com/blog/building-products-at-soundcloud-part-2-breaking-the-monolith
- Karma: https://blog.yourkarma.com/building-microservices-at-karma
- Groupon: https://engineering.groupon.com/2013/misc/i-tier-dismantling-the-monoliths/
- Hailo: https://sudo.hailoapp.com/services/2015/03/09/journey-into-a-microservice-world-part-1/
- Gilt: https://qconnewyork.com/ny2015/presentation/microservices-and-art-taming-dependency-hell-monster
- Zalando: http://www.infoq.com/news/2016/02/Monolith-Microservices-Zalando
- Capital One: http://www.capitalone.io/blog/why-capital-one-is-at-aws-re-invent-2015/
- Lending Club: http://neo4j.com/blog/managing-microservices-neo4j/
- AutoScout24: http://www.infoq.com/news/2016/02/autoscout-microservices
There is no clear statistic as to how many small companies are using microservices. The following list contains a few projects where I personally know the people operating them and know they are using microservices:
- Fuelish (www.fuelish.de)
- ReviewSender (www.reviewsender.com)
- MyParkplatz24 (www.myparkplatz24.de)
- Vapor Cloud (https://vapor.cloud/)
Most companies mentioned here are very big and serve a lot of users. Likely, you are not in a position where you face the same problems; however, you can already learn from these companies to avoid making the same mistakes. Here are the key takeaways:
- Microservices are used across the board for companies with many users.
- Microservices were built not only for scalability but also for internal management.
- Microservices make a system complex.
- Many big companies started out with a monolith but turned it into microservices.
In this section, you have seen some of the big players who use microservices and their reasons for their decisions. Don't forget that almost all of them started out as a 1-3 people company and a monolithic system. If you want your app to grow quickly and efficiently, microservices will not disappoint you. Now, let's directly compare monoliths and microservices.
Let's take a moment and compare a monolithic application with a microservice application. The following diagram shows the most obvious difference between microservices and a monolith; monoliths are everything in one piece as opposed to microservices, which are split up in to different parts:
As you can see, the most obvious difference is that a monolith is one code base. Every code is within the same project and connected. In contrast to that, microservices are loose and independent but are often working together.
In the following subsections, we will compare concepts that highlight the difference between microservices and monoliths:
- Reusable code base
- Multiple versions online
- No downtime
- Updates are as slow or fast as required
- Common microservice use cases
Let's start by looking at the reusable code base.
This concept exists with monolithic applications as well as microservices. For monoliths, it's most commonly called plugins or modules. A lot of commonly used platforms are heavily utilizing this concept. Examples include WordPress, Magento, Drupal, Redmine, and Wikimedia. Many websites utilize plugins to extend the core functionality of the underlying monolithic system.
The underlying principle is to use the same code base across multiple use cases and projects. For monolith applications, however, all elements of that system will need to use the same programming language. For example, a WordPress plugin will need to be in PHP, just like WordPress. In opposition to that, microservices can be in various programming languages. You can have one service written in PHP but another one in Swift—they will work together just fine.
In a monolithic application, all parts are co-dependent on each other. If one part fails, all other parts are potentially affected. For example, one faulty plugin may cause the entire site to not load on certain or all parts. Microservices can be at various stages and not be impacted by others. Also, a non-operational service will not bring down the entire system. At the same time, it can be much harder for someone very familiar with one programming language and framework to work another piece in the same system. A monolithic application can be easier to maintain.
Both approaches allow you to reuse code; microservices, however, are a lot more flexible by allowing you to use various languages and versions together, whereas monoliths do not. Next, we will look at multiple versions online, another feature of microservices.
You can run two versions of the same microservice at the same time. If you have a user base that is using an old version of your API, for example, you can keep the old service available for them. Especially when updating apps, it often happens that not all users update to the newest version as soon as they can.
For the clients/users to differentiate between different versions of your service, you often use URL-identifiers such as https://api.domain.com/v1/users versus https://api.domain.com/v2/users
Notice that it contains a versioning string in the URL. The little v1 indicates that we want a specific version of this API service. We could run a second version of this service that is using v2 as an indicator and would return a different return-code.
You could, of course, deliver the same result using a monolithic application; however, in this case, you don't need to deploy two versions of the entire application but only this particular service.
Microservices allow you to keep legacy versions available without having to keep the entire old infrastructure alive. Let's take a look at how microservices allow you zero downtime.
As mentioned before, most hosting providers offer some Continuous Integration (CI) tools to keep downtime to a minimum. The principle is that you start the new version of the service first and then deploy it. Once it is up and running, the load balancer will lead traffic to the new service. Once the new service is fully functional, the old service will be turned off. The effect is that the user experiences no downtime.
A monolithic application can do the same; however, it takes a lot more work, energy, and server power to run a whole second instance of the entire application. If you need 100 servers for average traffic, you would need twice that many servers to complete deployment with this method. With microservices, you can only deploy the service in question while having minimal server overhead. Don't forget that most bigger updates usually require some database adjustments as well.
A monolith almost always uses one and the same database for the entire project. Even if you deploy your monolith in a way that two versions exist at the same time, it is a lot more complicated to do it with databases, especially when data is constantly being added or modified. On the other hand, each microservice is using its own database and you only need to work on the one you are updating.
Microservices are most efficiently used when they allow you to update with no downtime, which leads us to the next topic: updates are as slow or fast as required.
You can update only the services you want/need, allowing you to spread an update out. Especially for young companies and start-ups, it is widespread to have unclear and changing specifications. As changes and new features come in, you can gradually update your backend. For a lot of cases, adding features is equivalent to adding new services.
For example, if you have a social media app and you want to offer the functionality to comment on posts, it would only take you to add a Comment Service. This service would do nothing else but record comments on content.
If you are then tasked later on to add an "Answer" feature to your app, it could be an extension of the Comment Service. This feature could also alternatively be its own new service. Either way, adding these features can be done without touching the other parts of your backend at all!
To conclude, microservices allow for gradual functional extensions. Finally, let's explore common microservice use cases.
Here is a short, non-exhaustive list of the common use cases for microservices:
- Profile management
- Address verification
- Email handling
- Payment processing
- Social media streaming
- Order management
- Content management
This list can be extended by adding many more use cases to it. You might wonder how these small pieces of functionality can even function like an app. The next section will go into how to upgrade a monolith to microservices and explain how to draw the lines.
Upgrading from a monolithic architecture to microservices is essentially to continually replace parts of the old application with new microservices. While this section talks about upgrading a monolith, it can also be taken as a planning step for an entirely new application. You will see how to conceptually upgrade a monolith to microservices; there is no code mentioned at this point because you will see this in much more depth later in this book. You should, however, see the concept underneath after reading this section.
They may not fit your specific application but are generally widespread among monolithic applications. This approach is referred to as Model-View-Controller (MVC). The components of this approach are defined as follows:
- A Model represents an instance of a data type, for example, User, Product, and Order.
- A Controller represents a logic executor that typically takes input in and returns the output in the form of serialized models, for example, UserController, OrderController, and ProductController.
- A View represents an output from the controllers, often either HTML, XML, or JSON.
Many current web technologies are built on top of the MVC concept, such as the following:
- PHP (Laravel, Symfony, and Zend Framework)
- Ruby (Ruby on Rails)
- Java (Spring MVC and Vaadin)
- Go (Revel and Iris)
- Python (Django)
- Swift (Vapor, Kitura, and Perfect)
The goal is now to convert an MVC application into a microservice application.
Let's go through the following sections:
- Decoupling business logic
- Reorganizing your monolith
- Integrating microservices
We start by decoupling business logic.
We start by separating business logic. What is your application doing? Answer this question in terms of which aspects are involved. For an online shop application, the answer would look like the following.
The application does the following things:
- Takes orders
- Processes orders
- Returns products
- Creates products
- Updates products
- Deletes products
- Accepts credit card for an order
- Accepts PayPal for an order
You can be as detailed as you like with this list; it is not a final list of microservices. You will then use this list to identify common components.
By looking at the preceding list, we can easily tell that we are dealing with the following components:
This list is now a lot closer to what we want the microservices to define for us. You may still decide to combine one or two entries in this list but you can now see which microservices make the most sense for you.
You want to reorganize your monolith in a way that makes it easy to remove parts of its functionality to be replaced with microservices.
Chances are you will not be able (or want to) update the entire application in one big swap. Depending on the size of the project, it can take weeks, months, and even years for this process to be completed. If you plan on swapping your entire monolith with microservices in one go, you can skip this step. Companies such as Facebook have done this over many years while keeping parts of their old stack. However, even when you intend to keep some of your old monoliths, it still needs to be adjusted to work with microservices. The two main areas to adjust are authentication and business logic.
Microservices typically do not use a shared session model for authentication, which is a prevalent model for monoliths. Whichever model you are currently using, your microservices, as well as your monolith, need to interact with it. A very common and often used standard is called JSON Web Token (JWT); it allows microservices to authenticate requests.
You will need to modify your monolith to be able to communicate with microservices. There are more ways than just JWTs but because of their benefits and their popularity, I would recommend you use them. In essence, the following are the characteristics of JWTs:
- Self-contained (no central verification)
- Broadly adopted (every framework has a library for them)
- Easy to debug and troubleshoot
- A concept that allows easy security
You could also use a "shared session" token instead of JWTs; the principle remains the same: your monolith, as well as your microservices, need to be able to verify the requests.
Once your monolith can communicate with microservices, you can start to separate the business logic. A well-organized monolith application may have done this already. For example, if you are using controllers, you want to end up with the following for our previous example:
The reason you want to end up with a structure that separates the business logic is that you can then replace each individual component piece by piece.
So, adjust your monolith to communicate with your microservices and split it up to be easily replaced by them.
Now you are at a place where you can introduce your microservices. Each microservice should represent a piece of the business logic and should remain as independent as possible. Given that you have organized your controllers in a way outlined in the previous step, you will now be able to create the following microservices:
You can replace the services as you see fit and as your speed allows. Having your monolith optimized in a way that allows you to replace controllers by services will make this a painless process.
In this section, we learned how to approach integrating a monolith into microservices by decoupling the business logic, reorganizing the monolith, and then lastly, integrating microservices. Let's summarize this chapter!
In this chapter, you learned the basics of microservices. After defining them, you explored what a microservice is and how it functions. You looked at the reasons when to use microservices and when to not use microservices. After looking at current players using microservices, you saw a detailed comparison of a monolithic application and a microservice application. Finally, you learned how to conceptually upgrade a monolithic application to a microservice application. This chapter served as the basis for the rest of this book.
For you to make sure you understand the concepts so far, go through the following questions and answer them as best as you can. It is essential to be able to answer all of them or the rest of this book will make little sense to you.
In the next chapter, you will learn more about the current status of server-side Swift and why it is an excellent choice for backend applications.
To check your understanding of microservices, go through the following questions and answer them accordingly. You can see the example answers in the appendix of this book:
- What is a microservice and what is the definition?
- List three reasons why microservices can be helpful.
- List three reasons not to choose microservices.
- List four differences between a monolith and microservices.
- Draw a diagram of the infrastructure of the example online app in this chapter.