In the PaaS World, Azure takes the lead

Did you know that in the world of public cloud, Azure (not Google) is (a distant) second, behind AWS? I didn’t and was quite surprised when I came across this information and related data.

Since the launch in 2010, Azure has shown >100% growth. It’s 2014 revenue exceeded $1 Billion. Also in 2014, Azure grew by 125%. Their annual run rate is close to $2.5 Billion. And while AWS is still struggling to make that IaaS to PaaS transition, Azure has been recognized as a leader in both segments!

Looking at the growth, AWS has 27% of the market share (down from 28% last year), Azure, meanwhile has surged to 10%, up from 6% last year. GCE/GAE is less than 5% and IBM is about 7%. 

Finally, Microsoft has put all its cloud eggs in the Azure bucket. They want to be successful and are desperately looking for developers and customers.  In other words, anybody writing new apps has a big opportunity with Azure.

Among public cloud players (IaaS and PaaS), Azure could be the cloud of choice for you.

PaaS takes a leap forward

If there were any doubts about DevOps and PaaS being tied to each other, I think the reported growth in the PaaS  market should put it to rest.

MarketsandMarkets recently reported that PaaS in 2014 has grown to $1.28 Billion and the expected CAGR is upward of 32 percent.

So the question is what is causing such a huge uptick in PaaS adoption?

The answer is simple – rather than spending all their money on IaaS, a number of enterprise players including banks, telco and even providers of payroll services are recognizing the need for PaaS and experimenting with it.

Don’t get me wrong. This doesn’t mean the end of Data Center or private cloud. It just means that for a number of new apps, these traditional IT shops need new frameworks and auto-scaling, elastic infrastructure to support the app tiers – something that all major PaaS providers deliver but IaaS does not.

As we move forward and enterprise IT adopts cloud and develops DevOps mindset, we will see more and more teams moving to (private or public) PaaS.

What remains to be seen is if they will pay for the platform (Heroku, EngineYard, etc) or go with opensource versions of Cloud Foundry and OpenShift.

 

Adopting DevOps will help me solve……

In the last post I talked about a DevOps maturity model – a simplified set of milestones you could strive for to make your organization more efficient and agile.

The question “what will DevOps do for me?” still remains.

For Industry influencers DevOps is the harbinger of the new Industrial Revolution, something that will fundamentally change how we think about IT and various roles within IT.

For practitioners, still struggling to take that first step, the big vision is enticing but it is the smaller, more tactical goal that needs to be accomplished first to showcase the viability of DevOps.

Pragmatic thinking demands we help isolate one, may be two issues that these organizations can achieve in few months to an year’s time. Here is what I have noticed working for most Enterprise IT organizations

First – automate deployments. An average developer may spend up to 200 hours trying to set up the environment and deploy her application while still developing the code. Most end up writing there own scripts to make the job easier and repeatable. If however, they have a tool, blessed and available from IT, it would help them focus on code rather than how to deploy and test it.

Second – improve communication between your dev and ops teams. While “communication” can mean many things, I specifically mean “handoffs” from dev to ops. Instead of just handing over the code, the dev will now provide instructions, steps, deployment scripts, testing scripts and even known issues and defects to ops. This makes the job of ops much easier. If there’s a problem, then instead of just logging a defect, ops will now provide environment definition, data and even the state of environment before and after the defect occurred. This simplifies dev’s job of debugging the problem and finding the root cause helping them fix it faster and permanently.

So if you are looking for quick wins – start with deployment automation and look to improve communication, specifically handoffs, between dev and ops teams.

DevOps Maturity Model for Release Managers

Enterprise IT has come a long way in its understanding of DevOps. From “Can you show us DevOps” to “How do we start our journey to be more DevOps centric organization”, the maturity has grown significantly.  Let us take a look at the question again – “How do we start our journey…..”.

In other words, many IT organizations  are now looking for that first step or set of steps that will enable them to realize key benefits of adopting DevOps with measurable return on investment.

Screen Shot 2014-02-27 at 12.36.06 PM

My observation has been that Deployment Automation (also called Application Release Automation) is that first step. Most IT organizations find it a small enough step that doesn’t require too many approvals, can be localized to one or just a couple of environments (DEV, INT, QA, UAT, etc) and finally provides a quick ROI that can be shown to senior management to move to the next step.

The second step in DevOps Maturity Model is the one that most IT (especially the development) may have already tried – a controlled Continuous Delivery approach toward application release. The code doesn’t quite make it to the production environment automatically but could be promoted across lower level environments such as Dev and INT.

The third step  is establishing feedback and feedforward loops. Your development and ops may sit thousands of miles away from each other but if there are well established feedback loop, the dev will know the Operational Requirements  for a given environment and could include that in their initial designs. Similarly Development itself could provide information, scripts, instructions to deploy and test the code – the feedforward loop. A continuous feedback and feedforward form the crux of the DevOps practice. It is not easy to implement but it does give you huge benefits.

The fourth and the final step would be to establish a truly automated, DevOps centric Release Management practice. Here your deployments across all environments, with the exception of Production and Pre-Production is automated, continuous feedback and feedforward loops between dev and ops exist and everything that a human or a machine does is logged and audit-able.

While the organizations go down this path of developing DevOps centric organization, they continue to invest in infrastructure automation and management. That takes time and is an ongoing project which needs to be tweaked along the way.

That is it. There could be and will be more complex models but DevOps as a philosophy to be adopted doesn’t have to be complex. You have to start somewhere and Deployment Automation (also called Application Release Automation) could be that starting point.

What does Release Management Mean To You?

Over last year, I have talked to customers, analysts and industry experts to determine what is the definition of Release Management and how it fits in the world of DevOps. I have noticed that there are two different perspectives on this.

Analysts include everything, from Development and QA to post deployment monitoring (Application Performance Management) to be part of the DevOps problem.

Enterprise IT however, has a different take on it. As of now, IT  practitioners in most organizations equate DevOps with Automation – Infrastructure and Application Release automation to be precise.

Based upon the feedback from enterprise IT, I developed an image  which shows the relationship between Release Management and other IT disciplines as they understand it.

EIT RLM

The idea is that at its very core, the purpose of Release Management is to move software to a target environment – be it in your Datacenter or Cloud.

In doing so, Release interacts with Planning, Development, Testing, Ops/Deployment to collects status and track milestones.

To reiterate, DevOps means different things to different people but from Enterprise IT perspective I have found that most common definition includes deployment automation (App Release Automation) and Infrastructure Automation/Management.

I see that even though Deployment is somebody else’s problem, Release Management finds itself in the middle of deployment issues if the “handoff”  fails.

What do you think? Does your organization view Release the similar way?

When to consider PaaS in Enterprise IT

A few days ago I talked about the merits of Platform as a Service (PaaS) to help bridge the Dev and Ops divide.  However, PaaS adoption in Enterprise IT remains slow and faces several challenges – some perceived, some real.

Of perceived challenges, the most relevant is the one about security. A banking, insurance or health care IT does not allow hosting (and even developing) of applications in the Public Cloud – which is what the PaaS vendors offer as their primary service.

As a response, a number of these vendors have launched “Private” PaaS – where they offer their technology to enterprises and allow them to host it in their Private Cloud (read – infrastructure within IT’s firewall).

However, from those of us who have worked in Enterprise IT or are intimately connected with it, several challenges, including complexity of deployment, support for thousands of existing apps and problem of fragmented technology still remain. Lets take a look at each of these quickly and discuss alternatives or strategies to adopt the right Cloud for IT.

Complexity of Deployment

Using PaaS is quite simple but if you take the bits and deploy it on your own, the process becomes quite complex. You still have to download all the components, like a web server, app server, messaging service, database that the PaaS would use and wire it together using the PaaS  core that would manage the underlying infrastructure for you.  The process could be time consuming and difficult to manage. However, once you have invested time and resources on the initial setup, management is quite easy (unless you find bugs in the PaaS management components).

Support for Existing Apps

This is one of the thorniest issue that no PaaS provider is willing to talk about. IT organizations have thousands of applications and over 80% of dev time is spent fixing issues with these apps. Of the remaining 20%, most of the time is spent extending these apps and hardly 2-3% is dedicated to developing brand new apps from the scratch. That basically means that all the effort you’d put into PaaS would benefit only 2-3% of what you do. Is the investment really worth it?

Technology divide

Unless you are writing a web app using Ruby (Rails), Java (Spring, Scala) etc., PaaS is not very useful for you. There’s limited support for J2EE and .NET. App servers like Weblogic and Websphere are also not handled gracefully leaving you with a very narrow definition of what exactly is a “Platform”.

Alternatives

First alternative is what the PaaS vendors have been talking about. Adopt PaaS as is for the new web apps being built using modern frameworks like Scala and RoR.

If however, you’d still like to consider private PaaS, my suggestion is to wait. PaaS solutions are still maturing and while they do simplify management of app stack, they could be a hassle to deploy and upgrade and may not be worth the effort and cost at this time.

If you’d like to play with PaaS for some new, experimental development, I think there’s a better option. Adopt a more flexible IaaS option. AWS by itself has added a number of  PaaS like features under its “Elastic Beanstalk” service. With support for Java and .NET apps and auto-scaling features, I don’t think it is too much of a stretch to call it a PaaS. The most beautiful part of AWS EB service is it allows you to control how much or how little control you want over the app stack and where you want it to be available.

Mind you, you are still outside of your firewall but looking at the capabilities and simplicity that AWS brings to the table, I find it a much better solution for Enterprise IT.

Agility Vs. Rigor

Recently I came across two very different IT organizations. One, a cloud based software vendor that provides Payroll services to millions around the country and other an Insurance company.

You’d think that when it comes to software development and release  the software company would have more agile processes while the tradition financial company would focus more on rigor.

The reality is quite different.

Because they dealt with Payroll and each change could mean a direct financial impact on millions of users, this software company preferred rigor over agility – almost as much as any financial organization would.  The Release team recognized that even though the development had gone Agile they (the Release team) was still responsible for .making sure that the code goes through right gates before it is released for end users.

So the obvious question is – Do we have to choose between Agility and Rigor? Can’t we have both?

The answer is –  You CAN have both.  In some cases you even improve one by focusing on other.

Let me take an example of another IT organization, an Insurance company out of UK. With offshore and outsourced dev factories, the Release team was struggling with lost dev time as developers had to wait for days or hours for deployments to go through and testing to complete before they could fix issues and move to the next stage.

By adopting a deployment automation (Application Release Automation) solution, the release team accelerated their cycles several fold freeing up valuable QA resources who were previously engaged in deployment activities. These QA resources could now focus back on testing and bringing rigor to the release cycle – work they were hired to do in the first place.

In short – by accelerating their Release cycles and automating as much as they could, the release team was able to bring more rigor to their processes, eliminate dev downtime and improve overall quality of the release.

Is DevOps making Release Management Obsolete?

There’s a remarkable difference between those who work in Bay Area for one of the Cloud, Release or dare I say “DevOps” vendor and  those who live elsewhere and are employed by enterprise IT shops  at banks, healthcare, telecom companies.

Bay Area DevOps enthusiasts believe that the role of operations within Enterprise IT will be eliminated over next few years. Developers, they argue are writing scripts to deploy their code anyway. They could hand over the scripts to engineers on the ops side who could then deploy the code using these scripts and environment definitions that were delivered to them.

Open source tools from PuppetLabs and OpsCode have made the job of setting up environments quite prescriptive, if not exactly easy.

Deployment could be governed through in-house scripts or one of the ARA (Application Release Automation) tools offered by all major vendors, such as IBM, Serena, CA and a plethora of smaller companies.

Where’s the need for Release Management?

Not so fast, the folks on enterprise IT caution. You could turn your environment into code and automate all the deployments but anybody who has worked in a bank understands that when a major release rolls by, hundreds of applications get updated. How does automation govern the process of planning, developing, testing, delivering these thousands of changes? What about Audit and compliance requirements that financial institutions and health care providers must follow?

In short, automation allows you to get your app to the consumer faster but it does very little to protect you from legal complications that arise with each release cycle.

And that, I believe is the role of the Release Management team. They make sure that all engines including development, testing, deployment, environment management are humming in perfect synchronization with each other, avoid and resolve conflicts as they arise, make progress and challenges more visible and govern the process to ensure complete audit and compliance guidelines that their teams are required to follow.

How PaaS bridges the Dev-Ops divide

Platform-as-a-Service has many benefits including freeing the developer from having to worry about application architecture (middleware, db) complexities as well as worrying about capacity planning as app usage rises (or falls) over time.

There are other benefits that in a way could solve a few Release Management/DevOps problems.

Application deployment is incredibly easy with PaaS. A single line command in Heroku could push your code to the cloud.
$ git push heroku master
Really. It is that easy!
Building a repeatable deployment script is a child’s play!
If you like that, here’s something even better
Since PaaS is a complete stack with add-on services that developers use to write their code, PaaS adoption could help standardize environment across Dev and Ops! Once you have eliminated environment variance and automated deployments, you have created a solid ground to reduce Dev to Ops handoff and accelerated your release lifecycle.

IT is Dying. Long Live The IT

Analysts and some vendor have been proclaiming the death of the IT for at least a couple of years now. Their primary argument resides in the “cloud”.

The argument goes like this – With Developers adopting Agile and QA becoming more automated, the only barrier to moving code faster to production is IT (read Ops).  As business owners adopt more SaaS applications, Developers adopt PaaS and environments are maintained with IaaS (public or private), you wouldn’t need IT all.

Every single IT exec I have met looks at the argument above and shrugs his or her shoulders.  While every single Enterprise IT today has a Cloud initiative, it is crystal clear that core, strategic and business driver apps are not going to move to the cloud any time soon.

An Executive Director at one of nation’s premier Financial Services group summarized the challenge – “I manage the applications that are used for trading.  One wrong move, and the entire business (billions of dollars) could disappear overnight. To suggest that we will hand our applications or infrastructure over to a third party is just not realistic.

I believe everybody who comes from one of such companies could relate to that.

No matter how much automation and cheap and reliable cloud services are developed, IT is very much alive and kicking.

The reports of the death of IT have been greatly exaggerated.