The success of the implementation depends on three key items: in-house talent or software consultants; what actions the application performs, and whether or not you already have a prototype or legacy application.
If you’re starting from scratch, it becomes a lot easier to define how Serverless meets your needs. However, if you have an existing application, Serverless may meet your needs once you understand if your application is a microservice or monolith.
What is a microservice?
A microservice can act as a single block of functionality. A monolith is a tower of interweaving dependencies.
The monolith can be more tricky and time-consuming to transition to Serverless. The migration can be done with strategies based on the level of comfort your company can handle.
The easiest strategy is to build new features using fully managed (Serverless) services. An example of this could be as simple as a new REST API, which the monolith utilizes.
That REST API could use a cloud function written in NodeJS, where your monolith APIs could be in Java Spring Boot. You would also have that cloud function hook into your existing database or use a completely different, fully managed database. This allows you to dip your toe without over committing or spending time re-architecting.
The other strategy would be not extending the monolith and rebuilding the entire application using as many fully managed services as possible.
Rebuilding the entire application is a heavy lift and definitely not the first place to start. It also depends heavily on in-house talent or consultants. However, the deeper you go to create workarounds for existing systems, the more complex the integrations can become. In some cases, rebuilding the application is a necessary change.
Start from Scratch or Extend?
The transition from mainframes to Serverless usually requires re-architecting how the pieces worked together. In this case, options were to start from scratch versus extend.
When it comes to microservices, they have a bit of an easier time transitioning to Serverless. However, it does require internal adjustments similar to moving from virtual machines to Serverless, as a lot of the overhead behind managing the containers or servers is abstracted away.
Do microservices accelerate Serverless migrations?
The main advantage of having microservices installed is that you broke your application apart into small blocks already. That’s important because cloud functions serve a small, sometimes singular, function. Moving your microservices to Serverless skips the step of identifying which parts of the application can be broken apart. That saves quite a bit of time.
Why to start from scratch?
The final scenario is starting from scratch. This is a scenario where you’re building a new application and can introduce completely new technologies and services that may not correlate to your company’s legacy applications.
Starting from scratch allows more flexibility to rapidly accelerate development with Serverless.
Case Study
Frankfort’s Kubernetes on Serverless
Frankfort is a billion-dollar company that spends millions of dollars per year on servers. For a company with over 500+ employees, they are by no means small. They had developed a strong product and spent tens of millions in developing and maintaining their product and supporting services.
They had built this product before Serverless, or the software development industry was utilizing containers.
Problem
With the change in new tools and solutions such as Kubernetes and Serverless, the existing infrastructure, which worked for the most part, started to fall apart and show its holes when held up to the light.
The clock was ticking, as money was leaking. Frankfort had a decision to make, as the organization began to inspect where costs were flowing. The millions of dollars in server costs and millions of dollars in development and maintenance were becoming too complicated. Reducing the total spend and maintenance was of utmost importance.
Frankfort accelerated development
- Kill anything that shouldn’t be on.
- Reduce anything that was over-provisioned.
- Optimize, lower costs, overhead, and accelerate development.
As a first step, Frankfort began to turn servers off. Second, they started scheduling servers to only be on during certain periods. Finally, they took whatever was left and was part of their production applications, and began optimizing.
Solution
The optimization was gradual and required heavy lifting, as the application was tightly coupled. Frankfort’s main application was a monolith that needed to be carefully chipped away piece by piece while ensuring limited downtime for end-users.
Frankfort had to adhere to strong SLA’s (Service Level Agreements). Frankfort did not have the in house expertise to move in this new direction, so they hired outside consultants to fill the gaps where needed.
Results
Frankfort did not start to see large gains until making the legacy transition an organization-wide effort. By investing time in the killing, reducing, and optimizing,
Frankfort went from spending millions a year on servers to a third of the total cost. Frankfort’s focus on fully managed services and automation allowed the development teams and operations teams to level up in areas that accelerated releases and responses. In the wake of these great efforts, the Frankfort operations team started to fly under a new flag. The flag of the SRE or Site Reliability Engineer.
The development teams at Frankfort began to evolve into a service ownership model naturally. They were given more control to build and deploy their new features by leveraging the SRE team’s tools and other fully managed services.
Frankfort is a prime example of the impact that Serverless can have on an entire organization. Frankfort re-architectured existing monolithic applications extended existing monolithic applications, and built entirely new applications with a Serverless first perspective.
