Ready to start a project with us? Let us know what's on your mind.

1501 Broadway STE 12060
New York, NY 10036-5601

inquiry@winmill.com
1-888-711-6455

    Select Service(s)*

    x Close

    In the first article in this series of breaking down serverless architecture, we discussed the first tier: the front end. In this second article, we will take an in-depth look at the second tier: the middle tier.

    The front end of serverless architecture has very little centralized logic because its main function is to execute static pages in a browser. So where does all the application processing, whether it’s very simple (e.g., returning records from a database) or very complex (such as data transformation or data aggregation), happen? The answer takes us to the middle tier where the business logic and business rules of the application reside. 

    Business logic encompasses the business rules that determine how data can be created, stored, accessed, and changed. 

    Business rules describe the operations, definitions, and constraints of your day-to-day business functions.

    Understanding the Middle Tier of a Serverless Architecture

    The middle tier of a serverless architecture contains all the business logic and rules. It can process all user input and requests. In this type of architecture, the business logic is spread across multiple services. These services are fully decoupled from each other.  Each service is responsible for a single function of the application. 

    The guiding design principle is that each middle tier service should do one thing and do it well. For example, if your application requires user account management, then it should have a user service in the middle tier that deals with everything user-related and nothing else. Services like this will often manage data via a backend data store.

    When it comes to hosting these services, our design calls for the use of serverless compute solutions provided by your Cloud vendor. Serverless compute solutions such as Lambda, in AWS, or Function Apps, in Azure, are pay-for-use services that run only while executing a request. This means that you pay only when your code runs.  

    Because this type of hosting environment is managed by the Cloud vendor you don’t need to worry about the underlying infrastructure that supports it. All your team has to do is upload their code and add any application-specific settings (such as runtime version) required. Scaling, patching, upgrading, and all other infrastructure management tasks are taken care of by the Cloud vendor. Your team just has to manage their code.

    Serverless Architecture Middle Tier Structure 

    The Cloud-managed API gateway is a public API gateway that can give front-end users access to your application. The REST APIs (Representational State Transfer Application Programming Interfaces) are used to enable the four basic functions of data management: create, read, update, and delete (CRUD). Users can perform these operations in the application according to their security credentials.

    The middle tier of the serverless architecture has evolved from the early days of application development. In those days, remote procedure calls (RPCs) were sent using simple object access protocol (SOAP) or web services description language (WSDL). Now, however, our recommended middle tier design uses REST APIs to execute the business logic. 

    A serverless  middle tier has several benefits:

    • Scalability
    • Flexibility
    • Portability
    • Independence
    • Cost-effectiveness

    A RESTful microservice middle tier is the key to being able to decouple applications that were written for a monolithic architecture, where every single piece of business logic was run within one execution environment. Applications written for a monolithic architecture have inherent potential problems.

    One problem is dependency. If all of the application’s business logic resides within a single, large body of code, and part of the code fails, the entire application fails. Another problem is latency. All the code in the application has to be read when the user makes a single request. For example, the application may need to run through dozens (or hundreds!) of if-then statements to get down to the lines of code that execute the user’s request. If many users are making the same request at the same time, response time might suffer or even the entire server might crash.

    These problems with monolithic applications are eliminated with applications written for a serverless architecture. In a serverless architecture, business logic can be broken into single functions, called microservices, that operate independently. 

    A good way to understand microservices is to think of them as components. For example, a car manufacturer uses many components, including tires, bumpers, doors, door panels, hoods, steering wheels, and brakes. Although these components work together, they are fundamentally separate. These components sit in inventory until individually needed in the process of assembling a car.  

    The same principle applies to microservices. Serverless microservices run only when that particular function needs to be executed. You are charged only for the time a serverless microservice runs; you aren’t paying for the microservice when it’s not running. Using serverless microservices is both efficient and cost-effective. If you are paying for a service (excluding license costs) even when it is idle then it is not truly serverless.

    Serverless Architecture Middle Tier Best Practices 

    Examples of best practices for a serverless architecture middle tier:

    • Think through the design before you build the web service. The design of your web service will determine how well the business logic in your middle tier works. Avoid making a microservice responsible for multiple parts of your application. Each microservice should deal with a single component (such as a user, unit of production, employee, and so on) or record. Each microservice should do one thing and do it well.
    • Develop in the Cloud and deploy to your test bed constantly. You should have a test bed in your serverless architecture that mirrors your production hosting environment. Testing your applications in the Cloud allows you to address problems early on and avoid the pitfalls of waiting until a release to see how your code behaves in a serverless environment. By constantly deploying to your test bed, if something breaks, you will know it was one of the functions you implemented that day.
    • Conduct end-to-end testing regularly. The end-to-end testing should hit RESTful endpoints with data, the way a user interface would. Some of this testing can be implemented using automated testing tools and processes. 
    • Create one pipeline for each service. This makes deployment of upgrades and new code easy and efficient. 
    • Make sure you deploy microservices to the right type of Cloud service. This is not always obvious. For example, Kubernetes (a cluster and Docker container management tool) is not serverless. If you deploy to a non-serverless Cloud service, your application won’t run like it would in a serverless architecture. Traditional servers and even containers will run constantly as opposed to upon request, and there will be no built-in scalability or proper management of bottlenecks, CPU usage, etc. How can you tell the difference? If the application runs all the time and you’re paying for it even when you’re not using it, then it’s not serverless.
    • Protect all your web services. Thoroughly secure the web services that should be private, such as customers’ personally identifiable information (PII) and business data. Ninety-nine percent of the time you should avoid using a public API. Instead, you should authenticate every user request (via a web-compatible authentication token such as Java web token). Every service must do its own independent authorization and authentication. 
    • Use an API gateway for the middle tier. Behind the API gateway, you should have firewall restrictions that define what can connect to the service itself. The gateway and your internal services should be the only things that can connect. Your services should be independent, but designed so they can exchange data with each other in real time. A Cloud-managed service bus is a recommended solution to API intercommunication.

    Advantages of a Serverless Architecture Middle Tier

    Your code and your microservices change less often because they aren’t dependent on each other. You can change your entire front end or application logic so that everything around them changes dramatically, but updates to many of your  microservices may be minimal. 

    It is very cost effective. Instead of paying for 24/7 runtime, you pay only for the time when your microservices run. And you’re assured, because you have the Cloud provider managing the underlying infrastructure, that you reach and stay at the five 9’s uptime goal. 

    Almost any existing application can be turned into a serverless application with the business logic in the middle tier. It’s mostly a matter of taking your existing application’s business logic apart and making each function independent. This requires time and money in the short run, but your company will reap many benefits—financial and otherwise—in the long run.

    Check Out Our Other Content

    Back to Blogs