CloudServerless Architecture Offers Business Benefits

How much time does your team devote to maintaining your cloud infrastructure: building servers, setting up services, OS upgrades and patches, maintenance, and so on?

How much time do they spend trying to develop applications that fit into the limits of your infrastructure? How much time do they spend checking disk utilization, requesting more memory, or configuring auto scaling? And how much time does your infrastructure team worry about system uptime, backups, and disaster recovery?

If your answer to any of these questions is “too much,” you may be a good candidate for going serverless.

“Going serverless” doesn’t just mean that you are hosting your applications in the Cloud. In fact, traditional cloud hosting is based on virtual machine servers. Rather, “going serverless” means that you build your application using Cloud-native infrastructure provided by your Cloud provider (Amazon, Microsoft, Google, et al). There is no operating system to patch, memory to allocate, or disk space to reserve because these are all inherently provided by the Cloud architecture provider. The concept of “server”—in the traditional sense of the word—no longer applies.

Benefits of Going Serverless

When you transition your application to serverless hosting, you can focus your IT resources on managing your applications (code, databases, etc.) instead of on your infrastructure. Cloud environments provide an extraordinary array of inherent capabilities to manage capacity, memory, storage, bandwidth, clustering, replication, backups, disaster recovery, business continuity, and more. It can be complicated, but, in the end, it is ultimately more powerful and easier than implementing the equivalent functionality in a traditional virtual-machine-based cloud architecture. Thus, the amount of time and resources you need to dedicate to your cloud infrastructure drops dramatically.

The beauty of going serverless is that you are now developing applications “in the cloud, for the cloud.” This is referred to as “cloud-native” development, where your application code is built to take full advantage of your cloud architecture.

In a traditional server-based architecture, everything your application needs to run is on the same VM (virtual machine) or VM cluster. This includes the operating system, the web server, the application code, and databases. Therefore, all your code is written to run in the server-specific environment where it lives.

This is, in fact, an “anti-pattern”—a negative pattern that makes a small problem into a bigger one. In this case, the anti-pattern is the practice of making everything tightly coupled and interdependent. This is a very common practice in traditional server-based applications. 

Going serverless forces you to start adopting better, positive patterns. It requires you to break apart processes, so they are independent from each other. For example, for transactional events the computing resources don’t run unless a request is made.  Furthermore, each instance of a serverless resource is responsible for a single aspect of the application (usually referred to as microservices). The guiding principle for each service is to “do one thing and do it well.”

A well-designed client-server application is typically modular enough so that if one business function breaks, other functions will continue to operate. But if the backend server fails (database hangs, operating system fails, disk space fills up, etc.), the entire application will fail.  In a serverless application, however, this is not the case because there is no single backend server. Each function operates independently, initiating and using the resources it needs, and then shutting down those resources once complete. Your applications become instantly and infinitely more durable.

You may relish the idea of not having to manage servers anymore, but you may need some help moving from your traditional architecture to a serverless architecture. Winmill has extensive experience decoupling and modularizing traditional server-based applications. We have Cloud engineers and software architects who do this every day.

Three Common Misconceptions About Going Serverless

1.    Serverless Applications Only Have a Static Front End

Serverless Cloud development is often associated with “static front-end applications.” A common misconception is that a “static front end” means “brochureware” (i.e., static, non-changing web pages). This is not the case. 

In a serverless application, a “static front end” refers to the static code (HTML, CSS, text) that is downloaded by the browser to display the page. But within the web application that uses this static code, you can create a complex, interactive website that is dynamic and responsive. The front end of a serverless application is called “static” because it is not prepared and rendered by a backend server.  When your website is designed correctly for a serverless environment, there are no limitations to what your front end can do. Winmill has helped many clients design their applications correctly for a serverless environment.

2.    Going Serverless Will Cost More Money

You may be under the impression that going serverless is more expensive than having traditional architecture. However, going serverless is usually less costly (depending on what you want to do) because of what you save:

• Fewer staff

• Fewer deployment and management costs (setup, installation, operating system purchases and upgrades, maintenance, etc.)

• No paying for idle time (resources on the hosting side charge only per request)

While going serverless is not a one-size-fits-all solution, most of the time we can design an optimized-for-cost serverless solution that is less expensive than a traditional server-based architecture.

3.    Serverless is All-Or-Nothing

A third common misconception about going serverless is that it’s an “all-or-nothing” proposition. Either everything is serverless or everything is running on traditional servers (typically virtual machines). The reality is that you can have a hybrid solution that helps you take advantage of serverless technology without having your entire architecture be serverless.

For example, you may find that a module in an application requires more dedicated resources than a serverless environment offers. In that instance, that module can be deployed to a traditional architecture while the rest of the application modules run in a serverless environment.

Types of “Going Serverless” Situations

When our clients decide they want to go serverless, their requisitions fall into one or more of these categories:

• Migration (“lift and shift”) – Take legacy applications and run them in the Cloud.  Ancillary functions that are external to the core application can be transitioned to be serverless, while the bulk of the application remains unchanged.

• Transformation – Rewrite and re-architect existing applications to be decoupled and modularized, both functionally and architecturally, and redeploy them using Cloud serverless components.

• New Development – Build new, Cloud-native applications designed for serverless architecture.

How Do You Go Serverless?

The first step is to talk with our Winmill team about your short-term objectives, long-term objectives, and your budget. We will determine the level of effort required to migrate or transform a legacy application; for a new application, we will review with you the software development life cycle (requirements, development, testing, etc.).

In the next phase, we will look at application load (for example, are there hundreds of millions of resource-intensive requests coming in per second, or is this a simple read-and-display application?). This is an area where expertise in cost and nuance of approach are critical.

Your architecture, and the degree of “serverless-ness” that you deploy, will be determined by your unique situation. When your applications are decoupled and modularized, the best solution may be all serverless or a mix. For example, you may decide that one high-intensity function needs its own virtual machine (VM), while the rest of the application functions can be built as serverless components.

If you’re considering going serverless, we can help. We have the knowledge and the experience in Cloud engineering and Cloud development to create the best solution for you to successfully go serverless.