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 in. 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 resource, 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 which 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 necessarily 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 in. 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?
Very probably, 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 which 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.
More Of John Arundel And DevOps
John Arundel on DevOpsA few months ago, in my post The Elusiveness of DevOps, I asked John Arundel of Bitfield Consulting what his definition of "DevOps" was. Now, we dig a little deeper in this interview in which John discusses DevOps.
What is your history with DevOps?
I'm the same age as the microprocessor. I wrote my first computer program in 1981 (it probably just printed out 'John rules' a bunch of times). The computer I had (a Sinclair ZX81) was a few inches across and weighed less than a pound. In the following years I worked on bigger and bigger computers: the biggest (a Sun Enterprise machine) had to be delivered on a flatbed truck and weighed about a ton. After that they got smaller again. Today I work on an iPad that's a few inches across and weighs less than a pound.
Read more...
The Elusiveness of DevOps
At ActiveState, we have always been focused on software developers, especially those that use dynamic languages such as Perl, Python, Ruby, and Tcl. The past few years building Stackato, our private Platform-as-a-Service (PaaS), has led us to deal more with IT departments, while maintaining a close relationship with developers.
We are seeing a common pattern. Those people who really get PaaS bridge the gap between development and IT. They care deeply about the whole system of creating code, deploying it, and scaling it. This mindset is often referred to as "DevOps."
Software development is a creation, and IT is the deployment and distribution of that creation. These have historically been seen as separate roles. However treating these work centres as silos can lead to problems. Instead of a simple production line, where department A passes completed work onto department B who then passes it onto department C, it is considered better practice to look at these things as a whole system, with strong feedback loops between departments, so that work can move through the system efficiently.
Read more...
-->
Trackback URL for this post:
http://www.activestate.com/trackback/3785