In a serverless architecture age, infrastructure still matters

Public clouds continue to climb the infrastructure stack with services that promise to take humdrum IT out of users' hands and unburden developers from infrastructure constraints. But as vendors push serverless architecture and other techniques that estrange users from the physical assets that underpin their applications, should developers even care about infrastructure anymore?

A panel of leaders from Bitnami, Microsoft and Pivotal all agreed developers should care about infrastructure, at least a little, as they discussed the evolution of infrastructure's role in the transition to the cloud at the Microsoft Build developer conference in Seattle earlier this month. The following are edited remarks from Corey Sanders, head of product for Azure Compute at Microsoft; Tad Brockway, Microsoft's head of product for Azure Storage and Azure Stack; Erica Brescia, Bitnami co-founder and COO, and Joshua McKenty, vice president of systems advisory group at Pivotal.

On the role of infrastructure in a serverless architecture:

Joshua McKenty: As a developer, I never want to know too much about infrastructure, but if you're building a distributed system, some of your code probably runs on a different server and there's a network hop in there somewhere. If you're writing serverless, or let's call it functions as a service, your functions are probably in different servers. So understanding the network, at least, is important.

Erica Brescia: Serverless is very exciting, but it takes a long time for things to move over, and infrastructure is something you still absolutely need to care about. All these wonderful applications we have already written care about it quite a bit. Serverless is another tool, but what we see a lot is it's being used to glue together different services that do care very much about infrastructure.

Tad Brockway: Infrastructure is being transformed, certainly, but serverless combined with some traditional infrastructure like storage -- that actually is a pretty powerful combination, because you can take all of your assets on premises or even your cloud-first assets and you can pool them into infrastructure and do interesting things without having to write a ton of code and worry about things like IP addresses.

On how much can be done so developers don't have to worry at all about infrastructure:

Joshua McKenty

McKenty: There's certainly a lot of development going on where you don't have to be aware of infrastructure. Where the line gets drawn is a place where you do have a performance concern. We have easy development going on and then you've got complicated network-sensitive, performance-sensitive development going on. You just want to be able to connect those two together to keep the teams that have to care about infrastructure as small as possible and as close to the infrastructure as possible.

Corey Sanders: The nature of some of the compute services and data services will dictate how much the abstraction can be fully maintained. When you look at something like SQL Server, there are a lot of assumptions about having the ability to configure and change and tweak and so on with sort of the core infrastructure, so it's hard to fully abstract that without it being a breaking change.

When you look at something like Azure Functions, what that's running on, even the OS it's running on should be mostly abstracted away, but even there it's challenging. We are working on Linux support for Functions ... it turns out Java runs a lot better on Linux than Windows, so the problem is that some of these abstractions are impossible to fully separate just given the history of these existing services that people are writing to.

On what a vendor should know about a company before it transitions to cloud:

Corey Sanders

Sanders: How are you modernizing? What are you leaving behind? What parts of your service are you containerizing? What parts are you building new and pulling down from a prebuilt container? What parts are you moving to a serverless-based solution? To me it's really: What's the journey you want to go on? So much of that is app by app; it's not even customer by customer.

Brescia: The first thing I would want to know is, why are you thinking of moving to the cloud? Are you trying to save money? Do you have a mandate to shut down your data center? Are you trying to move faster? Is this about a competitive advantage of some kind? Understanding all of that is really critical to guiding you down the right path.

The other thing is, what kind of internal resources do you have and where do you draw the line on the control-versus-ease-of-use spectrum? With more control you have more responsibility, and you may or may not care about having control or you may or may not have the internal resources to manage that control.

McKenty: A lot of folks are willing to change their tools or they're willing to change some processes, but when they talk about transformation, they imagine it as something that's happening to everyone else in their building and not something that's happening to them. You'll generally go halfway to as far a transformation as you can imagine, and if you can't imagine being that radical, then you're not going to get even close.

On how to get developers to care about infrastructure amid the rise of serverless architecture and other abstractions:

McKenty: The answer is to have language and frameworks so it makes sense to them. When it's part of the developer's worldview, they care. Start by deploying to production every day. Start with CI/CD. If the first thing the developer writes is their CI pipeline that lands in production, it's not, 'We wrote code and then we figured out the infrastructure that's under it.' It's, 'We thought about our code as a combination of infrastructure and code to begin with, and then we apply our mental model of what our software is supposed to do with that intersection.'

On the need to use all the latest and greatest technologies on the cloud:

Brescia: It's great to try new things and experiment with new services, but if you're actually building an app or service that needs to be maintained, you need to think about why you're doing it and what the purpose is and not just change for the sake of trying the latest, shiniest thing.

People really overcomplicate things ... you see people trying to pick apart their app into a thousand different services that are all talking to each other because that's the new hotness, and it's just not practical.

People really overcomplicate things. Some apps will run just fine in a monolithic, single-server environment and you're going to get all the business value of it. Then you see people trying to pick apart their app into a thousand different services that are all talking to each other because that's the new hotness, and it's just not practical. It's great for your weekend project to build something cool and learn about new services, I totally encourage that. But not when it's something you or somebody else is going to have to keep running over time. Figure out what makes sense and go from there.

McKenty: Even the people who work on Azure and run it don't know about all the Azure services. You are never going to. You don't need to. It's like that north star of, 'I have a project; I have a problem I'm trying to solve.' Focus on what you need for that problem. Don't try to be a master in everything in public cloud. It's going to change tomorrow anyway. Also, they're going to rename everything anyway. Avoid the FOMO feelings.