Serverless architectures are getting a lot of focus now as a next-gen application platform and potentially as a successor to containers on public cloud platforms.
The reason for the interest is clear: companies want to minimize infrastructure management overhead by relying on the cloud platform to orchestrate cloud services rather than managing virtual servers themselves.
Public cloud platforms have already removed the burden of managing physical infrastructure.
Now serverless architecture stitches together various cloud services so that companies can simplify IT management while automatically benefiting from the frequent release of new cloud service capabilities.
The leading cloud platforms have noted this interest and new serverless options are coming out seemingly every day.
Of course, there are plenty of caveats, such as having to fit within the constraints of the service or set of services, a lack of visibility into what was traditionally points of monitoring concern, and a lack of familiarity on the part of many development teams.
But even so, adoption of serverless is quite discernable.
I encountered my first serverless application last summer when a company came to Logicworks looking for a managed services partner.
The challenges were immediately apparent.
First, there was no infrastructure to manage.
Seems obvious, but from the perspective of an infrastructure MSP, were immediately looking for where we can add value.
Second, so much of the tooling and systems used to manage traditional infrastructure (or even fully virtualized infrastructure such as Amazon EC2) simply had no place in this world.
The challenges were like what we faced with the rise of containerized applications, but more so.
In a containerized system, we found ways to do intrusion detection, log aggregation and host-level monitoring because we still had access to the host OS.
In a serverless system, customers that must meet PCI, HIPAA or HITRUST standards will have to wait for serverless-ready solutions.
These are real challenges for an MSP and while solutions will come that help companies achieve specific compliance requirements.
The bigger question faced by our industry is: what we do when theres nothing to manage but the application itself.
We had encountered similar challenges with the rise of Platform as a Service (PaaS) but there was always room to run the more complex workloads that didnt fit within those constraints.
Now that the code is running directly on the services and the number and capabilities of those services have grown so much, the line between infrastructure and code is blurring even further than the traditional understanding of infrastructure as code (IaC).
Of course, while new methods and tools are always arriving in IT, almost nothing ever goes away entirely.
We still have mainframes and we will have monolithic applications running on traditional topologies for some time.
There will be room for an MSP to add value for a very long time.
But Im still prompted to think about our place in a serverless world.
As an industry, we want to do more than just manage what will ultimately become legacy workloads.
And frankly, keeping good talent requires that we keep working on the cutting edge in addition to older platforms.
Also, we need to be able to work with those risk-welcoming verticals to be experts as the platforms mature and come into use by the slower moving, more risk-averse businesses down the line.
The most obvious take is that we will move up the stack as weve already done, getting closer to and sometimes owning the code deployment process, integrating with cloud services and providing an overlay of governance and expertise.
We would need to take this one step further by participating in the application architecture, suggesting services and helping teams integrate them.
Given the rate of change, having an MSP focused on keeping abreast of the tooling would be an asset.
Another nuance that differentiates serverless from PaaS is that we can use serverless services like Legos to build a platform or PaaS solution ourselves.
This would be a welcome difference from PaaS in that we can assemble the services into solutions that match our clients needs more completely, then continuously improve that deployment as new functionality is developed.
Examples of this from our team have included writing AWS Lambda functions on a clients behalf, incorporating AWS Simple Server Manager into our existing automation framework, and gluing together both cloud-native services and third party ISV offerings.
We quickly came to appreciate the speed and interoperability these serverless services provided.
So, while we dont know the future of serverless, were keeping our eye on this next stage of virtualization and are well aware that we need to stay in front of it.
We are increasingly encouraged by what we can do on our clients behalf using the serverless ecosystem.
Frankly, any MSP worth their salt is or should be having the same concerns.
Ken Ziegler is CEO of Logicworks.
Send tips and news to MSPmentorNews@Penton.com.
See the original post here:
Serverless Architectures from an MSP's Point of View - MSPmentor