Orlando Florin Rosu - Fotolia
Have you figured out everything you need to know about managing and operating container environments already? How...
to host them in your production data centers at scale? Transform all your legacy apps into containerized versions? Train your developers to do agile DevOps, and turn your IT admins into cloud brokers? Not quite yet?
I hate to tell you, but the IT world is already moving past containers. Now you need to look at the next big thing: serverless computing.
I don't know who thought it was a good idea to label this latest application architecture trend serverless computing. Code is useless, after all, unless it runs on a computer. There has to be a server in there somewhere. I guess the idea was to imply that when you submit application functionality for execution without caring about servers, it feels completely serverless.
In cloud infrastructure as a service, you don't have to own or manage your own physical infrastructure. With cloud serverless architecture, you also don't have to care about virtual machines, operating systems or even containers.
Serving more through serverless architecture?
So what is serverless computing? It's a service in which a programmer can write relatively contained bits of code and then directly deploy them as standalone, function-sized microservices. You can easily set up these microservices to execute on a serverless computing framework, triggering or scheduling them by policy in response to supported events or API calls.
A serverless framework is designed to scale well with inherently stateless microservices -- unlike today's containers, which can host stateful computing as well as stateless code. You might use serverless functions to tackle applications that need highly elastic, event-driven execution or when you create a pipeline of arbitrary functionality to transform raw input into polished output. This event-pipeline concept meshes well with expected processing needs related to the internet of things. It could also prove useful with applications running in a real-time data stream.
So with a serverless framework, where does the actual infrastructure come into the picture? It's still there, just under multiple layers of abstraction. Talk about software-defined computing. With this latest evolution into serverless computing, we now have perhaps several million lines of system- and platform-defining code between application code and hardware. It's a good thing Moore's Law hasn't totally quit on us.
Let's look briefly at all the sophisticated abstraction layers that we could stand up to build our own private cloud, serverless environment:
- At the bottom, there is going to be a physical server. Of course, we might need to revise our common concept of the physical box now that servers can be dynamically provisioned aggregations of component resources (e.g., cores, disks, memory, interfaces).
- We'd likely deploy a layer of virtualization on top of physical servers. A hypervisor will cluster host physical servers and, in turn, serve out ephemeral VMs. We might also add further cloud provisioning and automation services, such as those found in OpenStack.
- Into that virtual, cloudy environment we then deploy a container host cluster to provide container platform services, such as Docker, Kubernetes or OpenShift.
- Then we install our containerized serverless computing platform to provide application lambda services, such as Platform9's Fission.io.
- Finally, we can create and deploy our microservice application on this serverless architecture by submitting functional code bits that will run on top of all of those layers.
An application developer might only see and work with the lambda service interface, which can be fooled into thinking the whole invisible stack behind it really is serverless. This stack certainly transforms actual infrastructure to be more cloud-like in almost all facets. It's now dynamically provisioned, highly scalable, efficient, available on demand, elastic, resilient and able to make use of dense commoditized resources.
What does IT do now?
What does the serverless framework mean for IT? We've just explored the brutal truth that serverless computing really means there is yet one more abstraction layer to manage. And we haven't fully digested containers into our production operations yet. Can you visualize what's going on with your thousands of persistent VMs? Now think about tomorrow's expected 100,000 temporary containers, and maybe a million microservice ops per day. This could be where IT throws up its hands and points users to a public cloud.
But I think this is one of those key transitions where there is also a big opportunity. IT departments want to transform into internal service providers, and serverless computing is a great service to stand up. IT can use this kind of service offering to help shift its focus from running infrastructure to helping develop similar functionality that directly improves business operations.
IT can become something like ITDevs, providing leadership to the business in harnessing event-driven functionality (the foundation of most existing IT operations), cloud brokering (IT financial management), exploiting machine data (as an extension of IT data governance) and more.
In other words, use what we've been learning the hard way to improve over time actual business operations -- which, with big data, the internet of things, global, mobile and other trends, is looking more like IT every day.
Companies seeking serverless computing have options
Serverless frameworks can save IT money, but there's a learning curve
Will serverless put IT Ops out of a job or not?
Dig Deeper on Deploying Microservices
AWS Lambda alternatives for flexible cloud workloads
Combine containers and serverless to optimize app environments
When should I choose between serverless and microservices?
Combining serverless and microservices has its benefits