An increasingly popular subject in recent times is microservices. Microservices are a software development technique —a variant of the service-oriented architecture structural style—that arranges an application as a collection of loosely coupled services. For example, there are frameworks and standards from the 2000s that are designed to let you build microservices. A few that are popular at this time are https://apiary.io/, MuleSoft, OpenAPI (formally swagger), RAML. Also, we have two particular concepts that allowed microservices to become widely popular: cloud computing and containerization. Cloud computing allowed service providers to build, deploy and manage microservices in a virtual environment that was nearly limitless. Containerization created a new method for deploying software.
Users no longer need to be concerned about the version of the OS, the patches to the server nor the conflicts with other software on my servers or virtual servers. Considering these examples, along with the creation of a global web of sites and services, it was only natural that we moved from massive, do-everything systems to systems that were more specialized and focused on one or a handful of functions.
If you want to get more of an idea on what microservices are like though, check out some of the links below. The following are some great articles we recommend.
https://www.martinfowler.com/articles/microservice-trade-offs.html
https://medium.com/memory-leak/5-microservices-trends-to-watch-in-2019-fd2dbd33780d
https://blogs.mulesoft.com/dev/microservices-organizational-agility/
Still interested? Then let’s begin our top 5 trends in microservices countdown. Here, we will explain each trend, why it’s trending, its strengths, weaknesses, opportunities and threats (following Xentity’s SWOT model), and what it means for Microservices moving forward.
#5 GraphQL
Popularized by Facebook, GraphQL is a different take on web service development. GraphQL is an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data. GraphQL was developed internally by Facebook in 2012 before being publicly released in 2015. The main concept behind GraphQL, is it allows users to ask for what fields they want returned in a query. For example, if we had a microservice endpoint that returned first name, last name and age, and one that returned the former two and address, you would only get the fields you want once, rather than repeated times. With GraphQL, users get faster transactions and the ability to order a field according to your needs, avoiding redundancy and reducing network bandwidth.
GraphQL was originally introduced due to the growing amounts of data Facebook was faced with. Originally, when querying for particular types of data, we would see all of the data returned from the query, even the data you had no need for. Considering that it was Facebook, a social media giant, you can imagine the sheer excess of data they had run into while managing, that ultimately caused a massive amount of network bandwidth to be used when users were trying to have data values returned to them in queries. So, GraphQL came into play, reducing the number of microservices to only what the user needed and queried.
As great as this is, GraphQL is by no means perfect. You cannot link-track, which is when you track the number of clicks obtained by specific links on your website, in your emails, or even your social media posts. So, you need to take a more active approach to tracking who is actually responding, which is not always the best, most efficient solution.
#4 Microservice Catalogs and Registries
As microservices become more popular, they also become a lot harder to manage. Eventually, we begin to see different versions of the same microservices. And when you start having different versions of the same microservices, along with different microservices themselves, it is hard for users to determine what they should be using and what is available. So, there needs to be a method to start auto-registering not only the microservice but also the signature of the service. Also, what you need to interact with and what you can expect from the service. This is where these catalogs and registries come in. They exist to help users organize microservices and separate the outdated versions, from the current ones.
This trend also has its own bunch of weaknesses and threats. Namely, the concept of stale metadata, which is knowing when versions or APIs are no longer available. You’re also relying on software registration, so the microservice needs to register itself and provide the correct information. Otherwise, the catalog/registry will have inaccurate information. Catalogs and registries can also become severely bloated, and then searching becomes much more critical.
#3 ETL Pipelines With Functional Applications
To understand what these pipelines and their functional applications are, take a moment to visit sites such as Zapier and Ifttt. Organizations like these two basically say “you need to perform a set of actions that extract information and get you from A to B.” And there are people out there who are willing to pay for that company to perform that action for you. Companies can create revenue with microservices in this manner, like how Zapier integrates apps to pass along information between those paps in workflows. With this trend, we are seeing a growing market of businesses that provide microservices for a fee. This creates a market of experts on the subject, allowing clients who lack an understanding to receive the help they require.
However, this depends entirely on the adoption of using microservices versus writing microservices. If you are using microservices, weaknesses would be the lack of control you have over these services. Not being able to control these services can understandably give organizations pause. You do however have full control over incremental changes, you just have to maintain your ‘one thing’ and that it’s backwards compatible. That way, it doesn’t matter what direction you take it. It won’t break, regardless of who’s using it.
#2 The Field of API
This trend is a rather broad one, but we’ll condense it to two different concepts: marketplaces and low-code APIs. First, the marketplaces. Let’s say you have a service that provides thumbtacks. If you provide me those tacks, I will tell you some kind of ‘score,’ whether it’s a positive or negative response. Or consider geocoding, you have an address and want to know the location, we can provide results. Some people lack the infrastructure to collect micropayments, so certain marketplaces standardize the way they buy things, be it credits or billing cycles. For example, RapidAPI (Acquired Mashape Marketplace) and Algorithmia.
Then, there is low-code API. As we develop more software applications, it becomes important to integrate applications together, especially at a data level or functional level to help tie workflows together. This is where you get into low-code application frameworks. Appian is a good example of this. Being able to build apps on top of other apps by utilizing APIs, if they are well-understood, is easily done in the visual interface. The reason we build microservices is because you want them functionally segregated and easily integrated, and one of the biggest uses today is the low-code API platforms. As API becomes more popular, they legitimize and validate move towards microservices. And the best part is, no developer experience is required and analysts can create apps.
These API trends, however, share a few similar weaknesses. Namely, how becoming dependent on a platform can become catastrophic for an organization. This is what is known as “lock-in.” If the service you’ve chosen becomes unavailable for whatever reason, and you’ve built your business around that dependency, you’re in trouble.
#1 Serverless Architecture
And here we are, at our Number 1 Trend: serverless architecture. The move towards serverless architecture is essentially the move towards not having to worry about infrastructure. If you want an example of why this is so important, let us reference AWS (Amazon Web Services) Lambda. AWS Lambda provides low level to setup, supports API Access roles, computes on demand, meaning low costs. This is popular due to the rise of serverless architecture.
As Amazon is one of the internet giants of the world, you can understand the possibility of them being able to function at a faster, more efficient and inexpensive rate. Serverless architecture, as a whole though, removes the worry for infrastructure, administration, and low networking. Developing code for functions becomes greatly simplified. As you can see through all five of these trends, microservices is moving towards the idea of “building a better mousetrap.” More specifically, one that is efficient and simplified for users. If you want a better understanding of why going serverless is such a big deal in this case, check out our previous blog on serverless data pipelines.
But, like all our other trends, there are limits. Serverless architecture has limits on size, time and memory, compared to traditional software applications and services. If you’ve ever seen or used AWS or Google Cloud function, you know they basically charge you by the gigabyte/second. Therefore serverless architecture is typically meant for more small scale functions. Hence the meshing with microservices.
What Do These Trends Say About Microservices Moving Forward?
There is a lot that goes into answering this question. First, dome would argue that serverless is not microservices, and that it will take over traditional microservices. But there are others who would argue that it’s the “natural progression”. It simply needs a new definition like Pico Service (metric measurements, micro to pico). More metadata, less development. We fall into the school of thought that it is, the natural development. Also, the speed of app development and data integration will continue to increase. Apps are practically becoming a commodity now because of how easy they are to develop. There’s a whole new industry in managing microservices as they become more popular (managing, deploying, etc.).
Overall, microservices will continue to grow because there is short-term profit in use. They are easier to maintain. On the flip side, there may be a lot more turnover in both the technologies used to make microservices and companies that provide microservices. We will definitely be seeing more services become serverless and containerized and maybe more of a focus on architecture containerizing.
What Xentity Offers…
Xentity has experience building both microservices and serverless architectures, including REST and containerized solutions. We help clients understand the different “flavors” of microservices, as in serverless, containerized, and traditional. One of our big focuses has always been moving forward, we’re constantly thinking about innovation. Xentity can also help prospective clients with decomposing monolithic solutions and transforming them into modern day microservices.
The trend is to decouple these legacy systems that have to be rebuilt. Then, find how to break them apart and link them to individual services (our consulting services). We go in, analyze what a firm already has, and then proceed from there. Xentity can also help with metadata governance as well as microservice architecture in order to ensure that the advantages be fully realized. Xentity can also assess different software options to help the client make decisions on technology. And most importantly, we are ready to do all of this to help our customers.