The End of Servers. Hello Infrastructure as a Service!

By now, there’s a good chance you’ve grown comfortable with the idea of cloud computing, even if you still maintain an on-premise datacenter. The cloud has become ubiquitous, and headlines remind us every day about the mass adoption rates seen across many industries. You’re also probably warming up to the idea of Infrastructure as a Service (IaaS), where your team no longer physically manages anything beneath the hypervisor; instead, they count on cloud providers such as Amazon Web Services (AWS) to do it for them.

But what about serverless computing? This concept—what we like to refer to as event-based computing—takes things one step further. In event-based computing, the code is executed using only the exact computing resources required, not a smidge more, not a smidge less. Essentially, an event is triggering code, which then triggers the task. The big benefit here is that it costs far less to execute. It’s incredibly efficient.

Yes, there are still servers.

Calling this serverless computing makes us cringe a bit because, of course, there are servers, so let’s stick with the term “event-based computing.” It’s simply another layer of abstraction on your cloud infrastructure, relieving developers of the need to worry about servers (including virtual ones). The management is “abstracted away.” Developers don’t need to worry about anything other than executing a chunk of code, or “function.” In this way, you can think about a serverless framework as, “Infrastructure-as-Code.”

Imagine, for example, a user requesting a login or someone within your company uploading a file. These are everyday functions. In these cases, the function may only take a fraction of a second or a few seconds to execute. As soon as it’s done, it’s terminated by your cloud provider, no dedicated machinery required. In fact, you have no clue where your code was executed, only that it was done.

The leaders in event-based computing

Event-based computing is what many industry analysts predict to be the next ‘wave’ of cloud computing. So, it’s no surprise that all the major players are in the game, including AWS, Microsoft, and Google. But each cloud platform functions a bit differently.

• AWS Lambda. AWS Lambda was the first out the gate, in 2014.  To create functions in Lambda, you can either directly access the Lambda Console or use the Serverless framework. Within the Lambda console, you can upload your code – either Node.js, Java, Python, or C# – and use Lambda functions to call upon any one of about a dozen AWS services, including S3, DynamoDB, AWS IoT, even Alexa. If you choose the Serverless route, you can centralize the configuration of your functions into a single YML file. After that, you just need the function name that you want to use within Lambda, the name of the function in your code and instructions that tell Lambda when to execute it. The great thing about Lambda is that one event can trigger another event, which triggers another, and so on. Since architectures can get complicated, AWS X-Ray allows you to debug processes as they happen.

• Google Cloud. Depending on the type of function you’re seeking to execute, you may find Google Cloud slightly more intuitive, as its geared to HTTP requests. In other words, if you’re looking to execute HTTP, you may be able to do so with little additional configuration. What’s more, you can leverage Firebase to host your configurations, which removes the need for relying 100% on a console rule editor. Note: Google Cloud primarily sees its competition as AWS.

• Azure Functions. Azure has always offered Platform-as-a-Service features, but in 2015 it came out with defined function APIs, putting it more in line to compete with Google and AWS for these API-style execution needs. In Azure, functions take on a “worker role” – a job that occurs in the background and is implemented through WebJobs. To use Azure Functions, you must use Azure App Services infrastructure. Choose from the App Service Plan (where you can choose the size of the dedicated instances for every service), or a Consumption Plan, where instances are added or removed automatically.

For an organization that is new to event-based computing, there are no doubt nuances, benefits, and cons to each of these services. iT1 is experienced in each. We can guide you in which event-computing service is best for you. Let us know if you have questions, or if you’d like to talk about how event-based computing can streamline your cloud operations.