Continuous Delivery Among the Donkeys

26 Feb , 2015  

I was recently asked to give a brief overview of the mainstream market for continuous integration and continuous deployment and how companies are using it. The audience was a mixture of HeavyBit portfolio companies and their customers. So, it provided a nice mix of sellers and buyers. Since this topic comes up all the time in Pivotal conversations, I thought it’d be worth going over here as well.

Carrots on Heads, Please

Source: (PBF Comics)[]

Source: (PBF Comics)[]

I’m often fascinated—if agog in wonderment—at what the “elite” of the tech world are doing, those “unicorns.” There’s even “horses” out there—high performing organizations that are keeping up with those unicorns. But, I’m most interested in the normal folks, “donkeys,” as I like to think of them. I like seeing how the donkeys are doing when they strap a carrot to their head and try to keep up with the unicorns.

If you’re the type of person who wants the benefits of Cloud Foundry (making sure you’re shaving the right yak, focusing on application development instead of infrastructure development), you’ll want the benefits of continuous delivery, namely, speeding up your software delivery pipeline by automating as much as possible from builds, to tests, and even promoting builds to production.

These are outcomes of doing CD. The overarching goal is to reduce the cycle time to get new features into production, helping you establish a feedback loop that you then use to guide the perfection of your software. That last part is key, and often “money left on the table” when organizations stop short of changing their process.

So, let’s take a look at a quick survey of studies on how CD is doing out there in donkey-land.

Yeah. Everyone Wants a Pony. Astute Question, Boss

When I was at 451 Research, we did two studies of the DevOps market, from a donkey perspective. The first study had 201 participants, the second 300. We achieved a good cross-industry mix, not just people in the technology world. There were plenty of horses and donkeys in there. One of the first questions we asked was around each company’s desires to speed up software deployment. That is a core benefit of DevOps (perhaps the core benefit), and certainly a core benefit of continuous delivery.

In aggregate, the answer was painfully obvious—of course people wanted to go faster. Everyone wants a pony! Sliced up by industry, things got a little more interesting:

There are obvious ones who want to speed up like retail, entertainment, and SaaS companies. Industries like transportation can seem weird until you realize that IT-driven companies like Fedex, UPS, or even Uber are in that category (which is to say, there’s tremendous competitive pressure for IT to move faster). On the low-end, it’s sort of depressing that health care is less interested (I know I’d certainly like more, interesting uses of software when I visit the doctor), and perhaps things like construction are not so surprising.

When I look at this chart it helps me triangulate what types of industries are most interested in using software to change how they do their business. Those industries on the left side are certainly high on the list of people who’d be interested in continuous delivery, one would assume.

The Job To Be Done: A Platform for Speedy Software Delivery

With the desire to speed up software delivery frequency, we’ve found the job to be done. Now, a job to be done is a fun way of describing the problem a product or service solves—what “job” does a customer “hire” a business to do? I hire a hamburger to (a.) fill me up, and, (b.) make me happy. In contrast, when I’m on a long road-trip, I might just “hire” a gas station hot dog drowning in pump-chilli to fill me up, but not really make me happy.

In the realm of continuous integration and continuous delivery, there’s a clear job to be done—creating the “pipeline” for packaging up, verifying, and then deploying software into production. That is, everything between writing code and operating it. Someone once suggested to me that DevOps was simply the evolution of continuous delivery, which, while not entirely accurate, is useful framing. In that sense, I think it’s good to use one of the older but still useful process studies from the DevOps world, the software delivery platform:

Originally published in 2012, it’s stood the test of time and even popped up in one of the more useful cloud books of last year, The Practice of Cloud System Administration. CI/CD plays a huge, if not necessary, role in this process. One key point is to think of structured platform—moving code through this “pipeline” requires a lot of standardization and discipline. The alternative of re-inventing the packaging and infrastructure layers each time is the wrong kind of chaos.

There’s another vital part missing from the diagram, though, usually not from the conversation around it—a feedback loop. In addition to just getting software out the door more frequently, the primary business benefit of continuous delivery and DevOps (you see how those two so neatly dance around with each other?) is access to oodles of feedback about how customers are using your software.  This is used to hone and modify your software to better fit what your customers want, and one presumes <hopes>, that it leads to making more money from them.

Adapting to this feedback loop is the “money on the table” when it comes to process. I see very few donkeys taking advantage of those feedback loops, and the horses and unicorns even struggle with changing their process. Surveys and anecdotes alike show that people feel like things are often going wrong with their modern IT projects and often blame doing too little when it comes to change.

Speaking of Failure: CI/CD Use is Low in Donkey-land

Getting down to actual tool-usage, surveys from 451 and others, show a consistently lower use of CI/CD tools than you’d expect:

Here, you see the sad donut and some confirming, but encouraging survey data from DZone.

The sad donut shows that somewhere between 25–30% of the respondents are using CD tools like Jenkins, Bamboo, or hosted CI/CD services. There is a seemingly positive 35%, let’s call it, who are creating their own CD platforms. In past years, “rolling your own” when it came to service delivery platforms was needed and there was no other option. But, the technology is mature at this point, calling into question the strategic worth of DIY’ing your continious delivery platform. Effort spent creating your own CD tool is probably better spent on, you know, the actual software your customers use. The most distressing part of the donut is the near 30% of respondents who are doing nothing. I call this “distressing,” because, one, I like to be hyperbolic to keep myself awake, and, two, because CD as an idea and technology has been around a long time, well over five years. It is hard for me to imagine a software development team that wouldn’t benefit from it.

Now that I don’t work at an analyst shop, I can freely mix and match research data. So, I wanted to pull in some additional survey results on CD. On the right, you can see a year over year comparison of a DZone study, first listing companies who believed they did CD and then, according to a pretty good criteria based on orginization indicators laid out by Martin Fowler, judging which of those respondents are actually doing CD. Again, the results are somewhat shocking, but help triangulate the sad donut.

The Pipeline Is Your Platform, Perfect It!

For ease-of-thinking and strategic application, I wanted to simplify the software delivery platform diagram a bit. So, here it is with Pivotal colors!

There are a few things to think about:

  1. The most valuable part of this process is actually a handful of pixels—the first few steps where you’re creating the software used to help run your business. The feedback loop is clearly key to getting the right specifications in place and making sure you’re writing software that is actually effective. I believe these first two boxes are where most companies—most donkeys to be sure—should spend the majority of their effort (and yes, one should bundle test/verify in there, that’s always nice…).
  2. Over recent years, we’ve spent most of our time as an industry focused on the rest of the boxes, especially the infrastructure platform and production concerns boxes. Topics like cloud, OpenStack, and containers have made this area a churning pool of excitement. When I was an analyst and doing cloud strategy, I came across enterprises all the time who wanted to build their own platforms out of piece parts. For some—often the unicorns—it makes sense, or at least it used to. For others, it’s probably gold-plating and a mis-application of time and money. Unlike in recent years, there’s are so many “off the web” (to morph the old OTC idea) infrastructure parts that you’re likely better just using one of those rather than letting your people go crazy with the always entertaining task of building a platform.
  3. You also need to be on the look-out for fat boy scouts in this pipeline. If you lead an exciting enough life that you’ve read The Goal (a “business novel”), you’ll hopefully recall the lesson of the fat boy scout—your line of marching boy scouts will only be as fast as the slowest marcher. It follows that optimizing anything else before addressing bottlenecks is a waste of time. Focus on analyzing the whole process (i.e., the pipeline) and ruthlessly remove the bottlenecks. If you want an IT nerd version of The Goal, check out the more recent The Phoenix Project.

All of this raises a larger point. While we might think of all of this as Agile and the sort of cowboy codery that’s often associated with it…there’s actually a tremendous amount of discipline, process, and careful work involved in running a business with a continuous delivery engine. It’s much more than just using a tool. It relies on building out and perfecting the entire pipeline. The rewards are high, though—getting software out the door faster, making customers happier, which hopefully leads to more profits.

Let’s Fix the Sad Donut

From the anemic, but slowly beefing up, usage of CD we’re seeing out there it’s clear that we can do better as an industry. Almost five years after the publication of the Continuous Delivery book, there’s a lot of that half full glass to fill. In the meantime, the growing interest in developing mobile applications, cloud native applications,12 factor style applications, DevOps, and cloud in general has sparked a renewed interest in the otherwise sleepy,but always valuable, corner of the IT world, software development. Software development is suddenly very interesting and the focus of lots of great work and innovation from companies large and small. Indeed, HeavyBit’s investment thesis is that development tools as a market is fast becoming a big deal again; a strategic point that Pivotal obviously believes as well. Part of the goal of Pivotal Cloud Foundry is to provide as much as possible in the nature of structured platforms to slim up all those fat boy scouts in the pipeline. While the label “Platform-as-a-Service” has been and is certainly one that applies, we prefer to think of what we offer as a set of tools that helps our customer perfect the software delivery pipeline, that is: a platform.

Recommended Reading:

, , , , , , , , , ,


Forrester Wave Report: OutSystems Named a Leader in Enterprise Public Cloud Platforms for Rapid Developers

29 Dic , 2014  

The Rapid Application Delivery (RAD) and Platform as a Service (PaaS) markets are littered with solutions that attempt to solve various challenges application development and delivery (AD&D) organizations face today.

So when Forrester recently released their Wave report on Enterprise Public Cloud Platforms, we were pleased to read their advice on navigating this space and choosing an appropriate solution.

The analyst firm highlights the value of PaaS as it applies to three different use cases or developer types. We at OutSystems are proud to have been recognized as a Leader for rapid development.

According to The Forrester Wave: Enterprise Public Cloud Platforms, Q4 2014:

“Within the CIO’s domain, public cloud platforms empower AD&D pros with frameworks, tools, and consoles that speed creation, deployment, and ongoing updates. Select the right platform and AD&D pros will be highly productive.”


The trick is identifying the right platform. Forrester advises that organizations choose a platform based on their developers and their needs.

The Forrester Wave report defines three types of developers. The primary difference between them is the amount of resource control that they want or need.

According to Forrester:

  • Rapid developers want high productivity, not resource details.
  • Coders want to program, not manage infrastructure.
  • DevOps pros want configuration control when they need it.

We were pleased to see that Forrester identifies OutSystems as a Leader for rapid developers. We were recognized for having “extensive visual, declarative development and delivery tools, prebuilt applications and application components, support for both web and mobile application creation, and rich continuous delivery and application life-cycle management tools.”

OutSystems Platform provides a no- or low-code approach to developing mobile and web apps once and deploying them to a variety of devices (iOS, Android, Windows Phone, web). In addition, DevOps principles like continuous integration and delivery along with application performance management are built into the Platform to support the entire application lifecycle. The Platform is designed to help organizations rapidly build and deploy quality apps, even if the organization has a skills gap. As Forrester puts it, “OutSystems includes extensive visual, declarative development and delivery tools, prebuilt applications and application components, support for both web and mobile application creation, and rich continuous delivery and application life-cycle management tools.”

To learn more about choosing the right PaaS solution, download The Forrester Wave™: Enterprise Public Cloud Platforms, Q4 2014.

The post Forrester Wave Report: OutSystems Named a Leader in Enterprise Public Cloud Platforms for Rapid Developers appeared first on Platform as a Service Magazine.

, , ,


Is Docker The Right Abstraction For PaaS?

19 Nov , 2014  

Is Docker The Right Abstraction For PaaS?
Docker has been quickly adopted by nearly everyone and incorporated into everything from cloud technologies, to continuous integration and build systems, to solo developers working exclusively on their laptop. Heck, even Microsoft is getting in on this! It was born in PaaS (dotCloud) and this is the place where it makes a lot of sense.

read more

, ,


The Cloud Foundry Jenkins Plugin

18 Nov , 2014  

Jenkins Cloud Foundry PluginThere’s a lot of interest in using Stackato in conjunction with continuous integration tools, and the most popular of those tools is Jenkins CI. Until now, the only ways to deploy your applications to Cloud Foundry or Stackato from a Jenkins build were to:

read more

, , , ,


Amazon declares war on Oracle (again) with new Aurora database

12 Nov , 2014  

The first reveal of AWS Re:invent 2014. Aurora a MySQL-compatible relational database engine to take on Oracle et al. Also lots of goodies for developers including continuous integration and a managed code repository.

Amazon declares war on Oracle (again) with new Aurora database originally published by Gigaom, © copyright 2014.

Continue reading…



All Things Pivotal Episode #2 – Why Customers Want To Use Pivotal CF

15 Ott , 2014  

featured-pivotal-podcastAs organisations change the way they create and deliver the software that underpins their business, a new and better method of getting ideas into code and into production is required. Approaches such as Agile, Continuous Integration and Continuous Delivery all figure into this equation—as does the cloud.

Many organisations have built “their” platform—only to discover that it can be hard to maintain and difficult to extend across multiple cloud providers. Another element is the desire to gain the ideas of the “best and brightest” in the industry as to how software should be built and operated—and automate all of that into a common framework.

A lot of industry focus is around what this Platform as a Service should look like, what it should do, and how it fits into the IT ecosystem. Add to this the rapid adoption of cloud technology, and the adoption of new development languages and frameworks and you have what only can be described as “interesting times”.

In this week’s episode, Simon shares insights on why organisations want to use Platform-as-a-Service, and a more detailed tour of Pivotal CF and its components. This includes some of the high level ideas behind the platform, why it is built the way it is—and looking “under the covers” as to the major components that make up the platform.

Visit to listen or subscribe.

As referenced in the podcast, an example of the scaling speed in Cloud Foundry.

, , , ,


All Things Pivotal Episode #2 – Why Customers Want To Use Pivotal CF

15 Ott , 2014  

featured-pivotal-podcastAs organisations change the way they create and deliver the software that underpins their business, a new and better method of getting ideas into code and into production is required. Approaches such as Agile, Continuous Integration and Continuous Delivery all figure into this equation—as does the cloud.

Many organisations have built “their” platform—only to discover that it can be hard to maintain and difficult to extend across multiple cloud providers. Another element is the desire to gain the ideas of the “best and brightest” in the industry as to how software should be built and operated—and automate all of that into a common framework.

A lot of industry focus is around what this Platform as a Service should look like, what it should do, and how it fits into the IT ecosystem. Add to this the rapid adoption of cloud technology, and the adoption of new development languages and frameworks and you have what only can be described as “interesting times”.

In this week’s episode, Simon shares insights on why organisations want to use Platform-as-a-Service, and a more detailed tour of Pivotal CF and its components. This includes some of the high level ideas behind the platform, why it is built the way it is—and looking “under the covers” as to the major components that make up the platform.

Visit to listen or subscribe.

As referenced in the podcast, an example of the scaling speed in Cloud Foundry.

, , , ,


DevOps and Cloud: How to Make Business Love IT

24 Set , 2014  

Can DevOps, a process for fostering a faster and more collaborative software development actually improve an enterprise’s profitability and market capitalization? In the not too distant past before cloud computing infrastructure paved the way for unprecedented business agility, the suggestion that IT could be anything other than a cost center — let alone a business driver — might have seemed improbable. Fast forward to 2014 and the cloud-first strategies that are driving customer acquisition for many large enterprises, and it’s clear that IT has a greater responsibility and larger role to play as a strategic partner to the business. But how?

Enter DevOps.

DevOps is a portmanteau that literally means that development teams and operations teams collaborate more closely together. In one of my prior lives I built and delivered a new SaaS offering for a traditional appliance and software company. The experience of not just building but also being in charge of operating the service made me realize that without the developers and operations folks collaborating very closely, there was no way that the SaaS offering would stay alive, remain healthy, and continue to evolve and grow.

But startups and SaaS properties aren’t the only places you can apply DevOps. Donnie Berkholz, an analyst with Redmonk, explains DevOps as a cultural change for organizations — it’s a removal of silos between teams. But Berkholz notes that DevOps can also be viewed much more broadly in the sense of facilitating better collaboration between businesses and customers.

DevOps Tears Down Silos

Although it has proven to be effective for startups, DevOps has stirred some debate with regard to its being enterprise ready. The Wall Street Journal tech blog, CIO Journal, recently featured several articles with opposing views on that subject, most notably a post by At Work-Bench venture associate Rachel Shannon-Solomon on “DevOps Is Great for Startups, but for Enterprises It Won’t Work—Yet” and one by TripWire founder and former CTO Gene Kim titled “Enterprise DevOps Adoption Isn’t Mandatory — but Neither Is Survival.”

Kim’s message is unequivocal: Enterprises ignore DevOps at their peril.

Because DevOps is becoming an increasingly common approach among RightScale customers, we invited Kim, Berkholz, and New Relic Senior Director of Enterprise Marketing Abner Germanow to lead a panel discussion on the topic, which we recorded and made available for everyone:

DevOps Increases the Frequency of Deployments by 30 Percent

Kim, in particular, is passionate about DevOps. He authored The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win and has been a part of a team collecting data on how more than 14,000 organizations use DevOps, specifically identifying the cultural and technical behaviors as well as the business impact of the highest performing DevOps teams. The team published its findings in the Puppet Labs 2014 State of DevOps Report. Kim says the team’s research revealed that the highest performing DevOps teams are significantly outperforming their peers. “We know that high performers are deploying code 30 times more frequently,” he explains. “We know they can complete those deployments in minutes or hours as opposed to weeks, months, or quarters.” And not only are high performers doing more work, but they are also getting far better outcomes, reports Kim: “In a production deployment, high performers are twice as likely to succeed, and once something goes wrong, they can fix the issues 12 times faster.”  

High Performing DevOps Teams

DevOps Impacts Your Bottom Line

DevOps not only favorably impacts IT, but it can also positively impact your bottom line. Emerging data from the Puppet Labs 2014 State of DevOps Report shows that business outcomes can now be tied empirically to high-performing DevOps teams. The findings suggest that high IT performance provides a real competitive advantage, and there are indicators that it plays a role in growing the value of publicly traded companies as measured by market capitalization.

“Our research found that high performers are twice as likely to exceed profitability, market share, and productivity goals, and if you take a look at their market cap growth, you’ll find they are growing 50 times more than the low performers,” Kim says. “DevOps is great for development, it’s great for operations, and it’s great for the overall business because the value creation mechanism inside organizations and the customer acquisition vehicles are almost wholly reliant on IT.”  

DevOps Increases Profitability

Can Large Organizations Benefit from DevOps?

Indeed they can. And our panel gave a number of specific examples of very large high-performing organizations using DevOps.

Kim pointed to SAP, which was able to reduce the lead time from from code committed to product from nine months down to a week (including setting up the test run and starting and finishing deployments).

Enterprises can look no further than fast-growing, scalable startups to see how DevOps can speed up innovation. Abner Germanow from New Relic referenced companies that focus on the ratio of developers to infrastructure: “AirBnB is a great example — all cloud and all AWS. One of the things they talk about is how they have only 7 infrastructure engineers and 100 developers.”

Who Is Doing DevOps

At RightScale, we’ve seen an upward trend in our customers using modern, agile methodologies including DevOps, continuous integration, and continuous deployment. The RightScale 2014 State of the Cloud Report revealed this as well, with 62 percent of companies surveyed claiming the use of DevOps. In addition, DevOps practices increase with cloud adoption, growing to 76 percent among the most mature cloud users. 

DevOps Adoption Increasing


Data from the Puppet Labs survey shows that although there is a higher percentage of high-performing IT teams in smaller companies, nearly 20 percent of large organizations also have high-performing IT teams:

DevOps for Enterprise

Create a DevOps Culture

Typically it takes someone with a lot of energy and passion to evolve a company from the traditional IT model of organization to the more efficient DevOps model. Those who do will succeed in breaking down the silos between dev and ops, between IT and line-of-business, and between companies and their customers. Berkholz offers these high-level suggestions for getting started:  

Kotter Change Management

The professional services team at RightScale frequently takes an active role in helping our customers with their strategic cloud initiatives and can provide you with a free consultation on using DevOps in the cloud.

For information on methodologies related to DevOps, check out the webinar Continuous Integration and Delivery in the Cloud: How RightScale Does It.


“Free Hugs” image courtesy of Grzegorz Łobiński and Kalandrakas (caption added by RightScale). Licensed under Creative Commons.

, , , , ,


The Great Divide: Reflections on the Public/Private PaaS Market in 2014

15 Set , 2014  

featured-public-private-divideLast week we announced an important new partnership with Cloudbees to bring a native enterprise Jenkins service to Pivotal CF (PCF). This provided a first glimpse at the power of Pivotal Network, a service catalog for PCF. Pivotal Network allows any private PCF installation to import additional scalable platform services from Pivotal and a growing ecosystem of partners. PCF then manages the health and scalability of these services natively.

As Cloudbees joined the extended Pivotal ecosystem they also exited their hosted RUN@ PaaS business, which they had previously offered on AWS. In a thoughtful exit interview the talented Steve Harris compared their four year journey into PaaS market to a high risk polar expedition. As a fellow adventurer with Harris in the platform market since 2010, I would sum up my own experience and many of the conclusions of his blog with this chart:

Screen Shot 2014-09-15 at 7.40.31 PM

The public platform space has been a brutal market for startups. The $212M Salesforce buyout of Heroku in late 2010 was a false positive, and confused VCs. The investments became irrationally exuberant and the results were predictably bad. Public PaaS startups were too early, under resourced and focused on the wrong segment to win big in this new market. VC funded plays such as Dotcloud, Appfog, Cloudbees, and even the mobile specialists Parse and Stackmob have all since ‘pivoted’ or been modestly absorbed into larger organizations.

Deep pocketed investment by the major cloud providers such as Google’s recent free $100k for startups made it even harder for independent cloud platforms to compete or raise additional funding (all while having to pay the IaaS providers).

Finally, as Harris observed Cloud Foundry executed well on a broad ecosystem play, creating the “Cloud Foundry effect”

“There is a Cloud Foundry effect: Cloud Foundry has executed well on an innovate-leverage-commoditize (ILC) strategy using open source and ecosystem as the key weapons in that approach.”

Pivotal’s popular shared Cloud Foundry service for developers, PWS, is priced at only $2.70/month for a small hosted application. Stuck between the rapid growth of AWS, Google, and the emerging enterprise standard of Cloud Foundry there just wasn’t margin left for the hosted alternative platforms to live on.

Why Private Cloud is Different

In contrast to the startup failures in the public PaaS market, the revenue in the private platform market is significant and growing exponentially. While many enterprises are leveraging public cloud, many of the “crown jewels” applications still reside in private data centers, along with the majority of IT budgets. This means that despite public cloud adoption, architectural standards often start in the private cloud landscape and extend out.

Executing in this segment generates large purchase orders but requires shipping installable enterprise software, multi-year R&D, and a large enterprise sales force (the last two points being beyond the scope of most VC-funded business plans). The deals are large because they tap into the enormous yearly spend on enterprise middleware currently dominated by innovation laggards like Oracle’s SOA Suite. These legacy products were designed for infrequently updated applications built for vertical scaling—two trends which are now out of date. As the Harris’ blog observed:

“Pivotal Cloud Foundry has produced partnerships with the largest, established players in enterprise middleware and apps. In turn, that middleware marketplace ($20B) is prime hunting ground for PaaS, and Cloud Foundry has served up fresh hope to IT people searching desperately for a private cloud strategy”.

While public only PaaS players have continued to exit the market, private software based PCF has racked up an impressive parade of enterprise customers migrating from Oracle middleware to a next generation private cloud architecture. In June, more than a thousand enterprise users gathered for the Cloud Foundry summit, speaking to the remarkable benefits of building an application centric private cloud.

Early pioneers like Corelogic’s Richard Leurig are betting their company’s future on a next generation platform architecture and breaking down years of siloed applications on heterogeneous infrastructures. The market is waking up from years of dealing with the complexity of legacy products and demanding a cloud API integrated solution. They are also transforming their development processes to be more agile, anchored on continuous integration with systems like Jenkins. This is resulting in earmarked budgets for large private PaaS build outs.

Screen Shot 2014-09-15 at 7.47.42 PM

As enterprises adopt PCF, it is changing their whole concept of private cloud. Line of business developers gain immediate self service access to rapidly test and deliver applications and APIs. Monsanto observed an immediate 50% reduction in LOB development time and costs with PCF and plans to standardize the company on it in 2015.  For infrastructure teams PCF’s minimal IaaS requirements and deep platform provisioning automation provides immediate private cloud features with just a few clicks and a thirty minute install time.

Customer demand to extend the platforms’ services catalog with Jenkins, Cassandra, Elastic Search, etc is overwhelming.  Even enterprise stalwarts such as SAP, and SAS have announced customers are pushing them to offer their software on Cloud Foundry based private clouds. Almost every day brings an inquiry from an existing ISV whose customers are migrating to the platform who wants to be part of the PCF service catalog.

The Next Four Years of our Platform Adventure

Heading into 2015, we are hiring hundreds of additional developers, operations, marketing and sales professionals, and ramping every part of the team to take on our forty billion dollar enterprise opportunity.

Screen Shot 2014-09-15 at 7.51.02 PMThe public only PaaS meme centered on hosting, and missed the true revolution in software architecture happening in enterprises. This allowed Cloud Foundry to germinate in R&D for several years and surprise existing vendors, who prepared for the change merely by offering their existing legacy products on demand. Oracle kept its decade old middleware architecture focused on heavyweight J2EE but enterprise applications are moving from heavyweight client-server legacy model to a mobile centric paradigm dominated by REST APIs and microservices.

The production ready PCF platform has emerged as a way for enterprises to deliver on an ambitious private cloud initiative, ready for mobile APIs and microservices based applications. It delivers highly scalable, highly available services, fully automated on any cloud, with an easy to use developer API perfect for agile teams.

Using PCF is believing, and after one recent successful pilot, a bemused Fortune 50 CIO asked me, “IBM has been promising me this level of simplicity and automation for years, why  are you able to pull it off while they failed?” I answered, “Only by bringing the discipline of modern cloud architecture to enterprise applications were the efficiency gains you witnessed possible. No one has ever brought a cloud native platform to the enterprise datacenter—until now.”

The next few years of this expedition are going to be very interesting!


, , , , , , , , , , , , , , , , ,


How to Migrate Your Java App to OpenShift

11 Set , 2014  

OpenShift Online recently announced crossing a new milestone. Over two million applications have been created on the platform! This is a significant announcement because it further illustrates how developers are migrating to Platform as a Service to help them rapidly create and deploy applications.

The news for the Platform as a Service space is not so rosy across the board though. I received an email this morning from the CEO of another PaaS announcing that they are shutting down their PaaS service to focus on Jenkins. This blog post will not delve into speculation of why they decided to shut down their PaaS but rather focus on how to migrate your application to the most popular open source PaaS – OpenShift.

Why choose OpenShift?

OpenShift is an open source Platform as a Service that was started at Red Hat with a couple of key tenets in mind.

  • Create a completely open and non-propriety platform
    • This is important because we wanted application developers to be able to work with the platform without having to learn a completely new set of APIs. Put simply, the code you deploy today on your own infrastructure will work on OpenShift.
  • Provide best in class support for the stack of your choice
    • OpenShift supports a wide variety of application runtimes including support for PHP, Node.js, Java, Perl, Ruby, Python, .NET etc. Not only do we provide first class support for these runtimes, we offer choices among them. Let’s take Java for example. We support Tomcat 6 and Tomcat 7, JBoss AS 7, JBoss Wildfly, and JBoss EAP.
  • Provide a world class continuous integration environment
    • OpenShift also supports the ability to add a Jenkins server to your application to ensure that your continuous integration and delivery workflows are first class citizens on the platform

What are you waiting for?

Now that we now some of the key reasons that you should choose OpenShift, let’s walk through how to migrate your application code to the platform. I am going to assume that you are using Java for the examples in the remainder of this blog post.

Step 1: Create an account

Signing up for an OpenShift account is a quick and easy process. All you need to do is head over to and click the sign up button. You may be asking yourself what information you have to provide in order to get started with the platform. I am happy to report that the only two pieces of information you need is your email address and password. That’s right, you don’t even need to provide a credit to start using the platform. This is because we offer every developer the ability to create up to three servers for free to get familiar with the platform.

Step 2: Choose how to interact with the platform

You can interact with OpenShift in many different ways including using the command line, leveraging the feature rich web console, or even using the Eclipse or IntelliJ IDE.

Once you have decided which method works best for you, click the provided link for instructions on how to get up and running:

Step 3: Create your application

Creating an application on OpenShift is quick and easy. All you need to do is provide the name for your application and the runtime that you want to use. For example, if you are using the command line, you would enter in the following command to create a new application called myapp with the JBoss EAP application server.

  $ rhc app create myapp jbosseap-6

Creating a new application on the OpenShift platform takes about 30 seconds to complete. Once complete, your application will be available worldwide at the provided URL and the git repository will be cloned to your local machine.

Step 4: Deploying your application

Now that we have our application created, it’s time to deploy our source code to the platform. If you remember from introductory section of this post, I stated one of the key tenets of the platform is for your application code to work as is, without modification. Because of this, all you need to do is copy your source files over and push them to your OpenShift server. To accomplish this, add your source files and enter in the following command from the root directory of your application:

  $ git add .
  $ git commit –am “Adding my source code”
  $ git push

Once you enter in the git push command, your maven based project will be compiled on the remote OpenShift server and then deployed to your gear. This process can take up to two minutes the first time you compile an application as all of the Java dependencies are downloaded. Don’t worry, future builds will go faster as the dependencies are cached on your OpenShift server.

Step 5: Add continuous integration with Jenkins)

OpenShift also allows developers to use the popular Jenkins server for their applications that are deployed on the platform. If this is something you are interested in doing, please refer to the following OpenShift Developer Center post for the full instructions on how add this capability:

Getting started with Jenkins on OpenShift

Next Steps

, , , , , , ,