Blog
Basics: Microservices and FaaS – a fad or a real difference?
Aug 10, 2020,

On today’s page of deciphering the hieroglyphs of IT languages, we are going to delve deeper into two prominent pioneers of software architecture. If you are not familiar with the basics, we recommend you visit our last post to be up-to-date with our “diary” program. In a way, microservices tries to go an alternate path compared to the traditional monolith style and has picked quite the fans along the way.

Microservices, by definition, is a software architecture pattern in which large software projects are broken down into “module” chunks. These are loosely coupled but independent of each other in their implementation. They come together to create an app, thus implying that communication is necessary and they do so through Application Programming Interface (APIs).

The past few years have been incredible for microservices’ growth and popularity. They are an example of a modular software architecture pattern, based on the philosophy that having a loosely coupled system, each module can be worked on independently and when deploying does not require the whole system to be shut down, is the right direction. 

Simply put, microservices are but another architectural solution aimed at reducing the complexity of mostly web-enabled applications. The traction this particular pattern got is also due to stemming from SOA(Service Oriented Architecture), an older approach designed to surmount innate disadvantages of traditional monolithic architecture.

History lesson

Coming from the knowledge of the multiple layers involved in creating a web application, which if you have trouble remembering or have not yet discovered you can read more about here, let’s consider an example in Java. First, we have the Presentation Layer (user interface), followed by an Application layer, which has all the bits required to perform the business logic side. Next in line is an Integration Layer that takes care of loose coupling between components of the Application Layer. The app is completed by adding in a Database Layer that is the switch for the underlying persistence system.

To run the entire application, that is to make it available to the outside world because so far it’s local, we need to deploy our package to an application server (Tomcat). But packaging your components into an EAR(Enterprise Application aRchive) or WAR(Web Application Resource) brings out a monolith at the end.

Some developers took matters into their own hands and decided to pave a way out of monolith this, monolith that, monolith wherever they look. However, in order to reach the shore safely, they needed to check which parts were missing from the ship. Below we will illustrate the holes of the monolith-yacht – developers are millionaires, right so it’s only right they ride the hottest and most expensive vehicles.

  • The growth of an application is undeniable, so the codebase behind it must equal the increase. By the late stages of development, the development environment can be overloaded each time it attempts to load the application, thus reducing developer productivity.
  • Since the application is packaged in one EAR/WAR, two main problems arise: changing the stack and refactoring. For the first problem, a lot of reverse-engineering is going to take place and is no easy task if the application size soars thousands of lines. As for the second problem, it makes life a living hell because changing one end can impact the whole application functionality.
  • A big problem is the point of failure in monolithic applications. If any single component fails, well you must bid farewell to the entire app. Now, imagine a modern-day website that has login and payment capabilities. Moreover, deploying the whole package means it must make use of a shared resource pool. Processing power is limited and at some point in time, because a badly written function bleeds resources, the whole application’s performance will go down.
  • Scaling monolithic applications such as EAR/WAR packages is accomplished only by horizontally deploying copies onto additional servers. Each copy will eat up the same amount of resources, which can put a dent in your pocket.
  • And at the basis of the monolith sits the most important flaw – development. You see, applications growing size is not the biggest issue going on. Eventually, developers will not be able to work independently on parts of the system without impacting overall development time.

Having cleared out the starting point of microservices, it’s high time we explored the value they can bring and the flexibility so daringly shown.

One of the important tasks that will inevitably have to be solved is scalability. There are multiple ways of scaling a system and going over would require a few more instalments in our Developer Diary. So to quickly get the point across, we will be borrowing an interesting concept from The Art of Scalability, the Scale Cube.

It involves three dimensions of scaling across the plane’s axes. The X-axis involves horizontal scaling (in a nutshell buying more servers to host your files). The Z-axis invokes scaling by splitting, data is partitioned and the application redirects several requests to the corresponding shards. This is a preferred scaling and optimization for databases, as they also need careful consideration when serving millions of customers.

And the last axis of our 3D object is scaling by decomposition. The various functions implemented in an app can be viewed as independent services that can be chosen to be deployed, as the name implies, independently. Clearing some schedule in development time is one thing, the other being a dynamic and flexible environment that is ignorant of all modules intertwined. Here is how it microservices shapes the design of our previous app:

Easing into microservices

Doesn’t that look slick? Everything is separated, or if you want to impress fellow programmers working under you, perhaps, use: “I like the separation of concern”. This new slate, of what could be your project, does come with its sets of sacrifices you must make to the lords of silicone. So someone should decide if microservices suits what you are trying to achieve with your product or service, otherwise you could peek into other patterns. We have recently provided an overview of software architecture styles, which might prove useful going forward. 

With that in mind, let’s have a look at what microservices do good and how many bent gold pins it takes.

Advantages of microservices:

  • No technology lock-in. Since the access to the module is provided by the underlying API channel, developers can use whatever language stack they feel will accomplish the task best, without having to worry.
  • Ease of understanding. As the modules emerge, simplicity is their beacon. It becomes crystal clear what you are working on without having to depend on others.
  • Faster deployment. Deploying becomes a breeze because of the smaller codebase involved.
  • Scalability. You can make use of horizontal scaling and a convenient pay for services system when going into the cloud.

Disadvantages of microservices:

  • Microservices might be a hot take and comes with fanatical followers, but it’s not free of drawbacks. The main issue of any distributed system is the API system involved in realising the communication between the modules. 
  • Complex communication railway. Since every module is independent, the requests between them must be realised through a carefully modelled and robust system. These additional bits add call latency later on.
  • More services. Sharding your databases or any other system for that matter requires additional resources to be invested in managing communication
  • Global testing is difficult. With a monolith application, you can just pop the package on an application server and connect it to a database. In contrast, microservices depends on each module being confirmed before testing takes place. Though, this is less of a problem when implementing a continuous development plan.
  • Debugging hell. Consider each service a host of its own set of problems that will require you to browse logs after logs.
  • Deployment challenges. You may be limited by vendors of where you can deploy your microservices since it’s a different take as opposed to a WAR package.
  • Kinda not that useful for small businesses. Microservices is a good choice to consider when your application has reached a considerable size. For small businesses that resort to a few web pages, it’s not worth it to add the complexity of managing API communication and dismantling into modules.

Microservices and FaaS

If you are looking to deploy your microservices application then what other best option than another hot trend on the market – FaaS.

Function as a service (FaaS), also known as “serverless” computing, is an option for deploying your applications in the cloud. It’s been around a decade and the idea has caught on quickly. The mainstream providers, Amazon released AWS Lambdas in 2014, and Microsoft made Azure functions available in 2016. 

Serverless computing is a method of providing services based on their usage. This architecture allows developers to write and deploy code without worrying about the infrastructure. A company is charged based on computation and does not pay for internet resources such as bandwidth or number of servers as seen in horizontal scaling. One common mistake is thinking that there are no more servers since the name has -less, but that is not the case. The servers have shifted places, and, for the better or the worse, developers need not be aware of what these servers’ structure.

In the early days, if you wanted your web application found on the internet then purchasing physical hardware and configuring it as a host was the way to go about it. The business trying to put out a website was also required to manage the server hardware, thus additional resources down the drain.

With the coming of the cloud, servers could be rented out. But the payment system involved purchasing a fixed amount of servers. A spike in resource consumption would mean the servers would overload and cause the application to crash, so businesses made sure to over-purchase servers for the sake of these critical moments.

The main attractiveness of serverless computing is allowing developers to pay-as-you-go. So the services you use, that is what you pay for. To put it in perspective, instead of paying a monthly plan for your mobile cellular data, you are charged only for the data you consume.

So serverless outshines everything?

Going serverless isn’t always the best option, or even feasible, for some applications. While developers could go into details about technicalities, the main idea is that there are design constraints and sometimes losing control over how the server operates can pose issues. But, let’s have a look at where it performs well.

The keyword here is Function. Your service needs to operate like a mathematical function. Each invocation must be stateless. No information is stored, therefore any subsequent request will not be able to pass on data.

As FaaS provides scaling on demand, it can only do that if there is no state management. So if your application is headed into the direction of models like RESTful, then you are in for a good treat.

Another well fit is an event-driven service. In this case, FaaS platforms use provided events to issue instances based on the number of requests.

Do I use FaaS here…?

The platform loads functions on demand, therefore they should start up almost instantly. Afterwards, these functions are put to the test with a request. As soon as the processing is finished, the function is terminated. This is the origin of state constraint but also a hardship for applications that rely on a lot of initializations.

For example, AWS has a limit of 15 minutes. Azure has a limit of 10 minutes.

While an API call will surely fit in this time frame, some scheduled jobs will not. And then there is the imposed hard limit on execution time. Having someone else run your code means you need to communicate what you want to run and communicate is another word for writing an API.

The advantages of using serverless?

Name a more iconic duo than DevOps and new trends, or weekly JavaScript, or a new sticker on a work laptop. Trends are good practice. Emerging ideas can become pylons for translating hype into usable services. However, even if you want to be like the cool kid on the block you must never forget your third-eye. What does serverless offer that my business line can benefit from? Will my team appreciate or scorn adopting serverless into our system? These are just some of the questions that should cross your “tabula.” Not a new idea, just reminding yourself that hype overconfidence can precipitate an out of business fall. 

So what’s on tap here?

Lower costs – Cost-effective option as you’re only paying for exactly what resources you are using.

Simplified scalability – Developers need not worry about the policies involved with scalability issues. The vendor takes care of it.

Simplified backend – Some freeway in coding as every function deployed can be independent.

Fast TTM – The time to market is reduced considerably, a courtesy of removing the cumbersome deployment. A considerable benefit is the ability to modify code on a piecemeal basis.

Disadvantages of using serverless 

Security – You are at the vendor’s mercy when it comes to security and may not have the visibility you need to ensure the vendor complies with regulations governing your use or storage of certain types of data

Cost – This item is repeated from the benefits list, but in some cases, FaaS can actually cost more than using dedicated servers, depending on the processes you are running

Testing hurdles – Depending on the vendor, you may have challenges when creating a test environment for your application

All in all

Microservices and FaaS are by no means a fad. They do have their use cases and come with a set of unique drawbacks left for developers to challenge. The popularity they got in recent years is well deserved and the core idea of having loosely coupled systems is the right direction.

As for when you should consider such software architecture patterns, it’s mostly aimed at mid to large-scale applications. Smaller apps (single page applications) are better off staying on the monolithic side. These being written, I’m quite aware this post won’t give you decision-making insights. For this purpose, reach-out to our DevOPS here to get a proper consultation and a clear roadmap to building outstanding digital experiences for your end-users.