Interview on PaaS
Join the DZone community and get the full member experience.Join For Free
This is part two of an interview we did with John Arundel of Bitfield Consulting. The first part was John Arundel on DevOps. In this second half of the interview, John talks to us about PaaS from his DevOps vantage point.
How might PaaS fit into an enterprise's IT strategy?
Most companies don't generate their own electricity; they just buy it. It's a utility. Electrons as a service, if you like.
We've seen the beginnings of utility computing with things like Amazon EC2 and other cloud providers, but all they give you is an IP address, some compute resources, and a shell dialtone. All the hard stuff you still have to do yourself.
PaaS is the next level of utility computing, which instead of offering customers bare metal to compute with, asks them what services they need and provides them. You want to run a web app? Okay, no problem, deploy to this IP address: we'll take care of the web server, IP configuration, failover, monitoring, backups, databases, software stack, and so forth. It's deployment dialtone.
Now I'm not saying you should outsource all the knowledge about that stuff. It's just a question of what resources you have in the company and what it makes sense for them to be working on. If your company makes consumer products and you just happen to sell them on the web, you probably don't employ a bunch of people who are world experts on web operations. You can get this expertise much more cost-effectively by using a PaaS provider or consultant.
On the other hand, if you develop software or provide online services that are intimately connected with the technology of the web, you probably have very smart and knowledgeable people on staff who know and understand these things. They can then work with a PaaS provider at a higher level, building more complex and powerful infrastructures and stacks. It's not a question of 'to PaaS or not to PaaS'; it's a question of where you draw the shifting line between the skills and equipment that you have in-house, and those that reside with your business partners.
What impact does PaaS deliver to DevOps?
DevOps people are all about doing the most with the least: the most performance, the most reliability, the best service—for the least money, with the fewest people, in the shortest time. That means a high level of automation and agility, which in turn means PaaS-like tools and technology.
Now, you can either build that PaaS yourself (generate your own electricity) or you can buy it. As a geek and someone who loves playing with computers and technology, I like to build stuff myself. As a business owner, I know that isn't always the most cost-effective, or even the most satisfactory solution. Even if I determine that I need to build a substantial platform capability in-house, I can use PaaS to experiment with different stacks and architectures before I make major investments of time and capital in my own. Even if I need a huge internal IT infrastructure with my own data centres and operations people, there will likely still be parts of my business that it makes sense to run on a third-party PaaS.
What should be considered when an organization is looking at deploying its own PaaS?
You always want to be looking at what's happening in the business and thinking where your IT needs will be in six months or a year's time and planning how to get there; as aviators say, staying ahead of the airplane. Some of these requirements you can fulfil internally, some you may need to hire people to do, others will need to come from providers and vendors. You may need more capacity; you may need less. What's certain is that there will be change. How can you best effect that change?
Most likely, part of your IT will be delivered by a PaaS provider, and that is a critical business relationship for you. It needs to be a provider that you can work with, that will scale with you, and that will support you. You want it to be well-integrated with your own systems, but not so tightly-bound that you can't switch to another provider if things change.
You need a good fit between the skills and resources in your own team, and those of the PaaS provider. That means some overlap (so they can talk to each other) but clear lines of responsibility (so they don't clash). Your staff needs to be involved at every stage, because they'll be the direct users of the service. You also don't want them to feel threatened, that their jobs are being outsourced by stealth. What you're doing (I would hope) is outsourcing the generic and largely solved problems, leaving your staff free to concentrate on the things that are unique and valuable to your business.
You can assume that, as with most things, you get what you pay for. If one PaaS provider is much cheaper than another, their service is probably that much less valuable. Instead of asking how to get what you need for the least money, think about how to buy the best service you can with the money you have.
An over-engineered bridge simply takes a little longer to pay for itself. An under-engineered bridge collapses. That's all the difference in the world (especially if you're driving across the bridge).
What is the future of PaaS (as it relates to DevOps)?
We've made some progress from simple bare-metal cloud machines towards full-stack environments, and I think we'll see that trend continue. But I think the real value-add for PaaS providers is going to be the DevOps-style tools, monitoring, and metrics that they provide.
Because DevOps teams are always experimenting and adjusting, I think we'll see greater configurability and flexibility in PaaS tools. At the moment many PaaS providers give you a pretty fixed stack that you can tweak a little bit. That's fine for many customers, but to get a competitive edge in web performance, you need fine control of the stack. That means getting direct access to the configuration management language, whether it's Puppet, Chef, or whatever.
Published at DZone with permission of Phil Whelan, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.