Right now, students all over the country are leaving home, starting university, and moving into their halls of residence. From my experience, that’s usually a single building, teeming with rooms, where they can get to know one another, collaborate on ideas, and share student facilities, like cooking. It’s a cheaper way of living too.

A true multi-tenant architecture, in other words.

This got me thinking about software development within that same multi-tenanted architecture.

First things first: what is multi-tenant? It is defined as a single instance of a software application serving multiple customers. These ‘tenants’ can customise some parts of the application, but not the application’s core. It’s cheaper because development and maintenance costs are shared, in contrast with single-tenancy, where each customer has their own software instance. Moreover, you only need to make updates once—in a single-tenancy architecture, the updates are endless.

Multi-tenancy can light the touch paper on your application development. As organisations embrace cloud, big data, the Internet of Things, and other digital disruptors that are redefining the role of IT in business, they need a proactive, comprehensive and dynamic automation strategy. Especially release automation, which accelerates the launch of innovative new services, while supporting reliability and control to enable the modern agile enterprise.

Multi-tenant release automation reduces TCO

As part of this digital transformation, organisations want to play in sandboxes: test-driving their neat new services and (mini) applications to make certain they don’t fall over in production. Automic is the only ARA vendor offering a multi-tenant service that can be deployed in the clouds. This enables enterprises to serve multiple departments and clients in isolation from each other on a single, shared multi-tenant platform, scaling for extremely large environments while driving cost of ownership down, simplifying operations, and maintenance. 

Here at Automic, for example, more than 300 customers have signed up for their own private sandbox on the Automic multi-tenant cloud. It operates on its own cloud, so organizations can get a feel for how the Automic platform can help drive digital transformation in a world of multiple rapid releases and deployments. This “try it before you buy it” service is the first of its kind in the release automation market.

This multi-tenant model isn’t just designed to help test drive Automic—it helps managed service providers (MSPs) and other large organisations kick sand in the faces of competitors. In cloud computing, the meaning of multi-tenancy architecture has broadened because of new service models that take advantage of virtualisation and remote access. MSPs, for instance, can run one instance of its application on one instance of a database and provide web access to multiple customers. In such a scenario, each tenant’s data is isolated and remains invisible to other tenants. It means MSPs can deliver great service to more customers at lower cost.

It doesn’t stop there. This multi-tenant release automation model helps large enterprises—saddled with slow-moving, legacy infrastructures—to bridge the gap between development teams launching mobile and web-based services almost non-stop, and the operations team who are more concerned with maintaining reliability and continuity. A multi-tenant release automation product enables organisations like these to be agile in the back end, and be compliant and scalable in the front office.

One more thought. Most university halls of residence are very tall buildings. Some so high they reach into the clouds. Even more reason to consider multi-tenancy release automation in the cloud.

(c)iStock.com/technotr

If you read IT blogs regularly, you would assume DevOps is already the status quo, that everyone has ‘crossed the chasm’, and are practicing continuous delivery on a daily basis. We read about all these amazing companies releasing hundreds of times a day using a mature DevOps model and release automation. Well, the reality is these exceptional companies are just that – the exceptions. Most companies are just setting out on their DevOps journey, and analysts predict they must catch up soon or succumb to digital Darwinism.

We see the business world being redefined by digital transformation via DevOps, so what is stopping you from following suit? As Tom Goodwin, an executive at the French media group Havas, pointed out, the world’s largest taxi company owns no taxis, the largest accommodations provider owns no real estate, the most popular media owner creates no content, and the largest movie house owns no cinemas.

Thus far DevOps has definitely had more of a development bias than an operations one

With this evidence it’s surprising that some companies are still scared to cross the chasm themselves. Having spent all their lives within the comfort of their established practices, they are hesitant to leave that safety. Even though they see other companies spreading their wings and reaching new heights, the unknown is always a scary prospect. This applies to cloud adoption for critical processes as well as DevOps.

DevOps adoption

An EMA survey from October last year found that just 25% of companies have a team known as DevOps, and this is an increase of just 5% compared to 2014. The study found that 97% had cross-functional teams compared to 60% in 2014. So in truth, DevOps is only just becoming accepted and established. However, these stats show that DevOps has finally crossed the chasm from hype to widespread adoption, and as with any leap of faith, it will take a while to settle and produce results.

There is no doubt that DevOps is needed to achieve a successful continuous delivery pipeline for bimodal IT: it is just a matter of time before it is adopted everywhere. The only problem is making the time for a transformation. With a constant backlog of work, changing an entire ethos can be challenging, but worthwhile. This excerpt from the 2015 State of DevOps Report says it all: “High-performing IT organizations deploy 30x more frequently with 200x shorter lead times; they have 60x fewer failures and recover 168x faster.”

Innovation is king

Thus far DevOps, has definitely had more of a development bias than an operations one.  It makes sense because a key point of avoiding or causing disruption in the digital business era is innovation, and innovation implies creation which is what developers do – create apps.

Ops teams tend to avoid using open source in the production environment – less than 10% of customers surveyed said they would consider it

At the DOES Summit I attended in November, there seemed to be a 70-80% dev presence. This reflects the level of innovation expected from agile coding practices these days, but we must also not sacrifice reliability, auditability and control.  The unbalanced scenario of ‘Big DEV, little ops’ can introduce unnecessary and costly risk. Perhaps agile practices suit a dev mindset more, but ops needs to be on board just as much.

As we have seen, bugs that are not caught in testing can cost companies millions when rolled out into production. A disaster such as those affecting the likes of the Wall Street Journal, United Airlines or Starbucks can cost the company more in terms of reputation and share price than successful DevOps can help them.

DevOps automation

Perhaps this is a fear for companies hesitant to leave reliable waterfall methodologies behind – they see DevOps adoption as accelerating risk or exacerbating existing challenges. In this respect there is much that the more conservative Europeans can take from their bolder US counterparts. However, DevOps is now mature enough for people to have learned from mistakes, and there are ways of rolling out DevOps across the enterprise in a controlled, incremental manner.

An automation platform from an experienced, established vendor can be used as a safety rope for the big leap. A repeatable, predictable Continuous Deployment pipeline can be built to amalgamate the best bits of SMEs’ knowledge from across IT departments or disciplines. This is then streamlined and tweaked over time with any superfluous manual tasks added to an automated pipeline, allowing SMEs to focus on deeper, more proactive work which leads to greater innovation and lower risk. In fact, automation makes DevOps possible. C. Little famously said that “DevOps isn’t about automation, just as astronomy isn’t about telescopes.”

Never blame your DevOps tools again

Choice of tools affects productivity along the deployment pipeline via both the suitability of the tools themselves and the job satisfaction gained by working with tools of choice. For this reason, a tool-agnostic automation platform is important, and this includes open source tools.

Agile coding practices may suit a dev mindset more, but ops needs to be on board just as much

The most successful DevOps teams complement specialised tools such as Docker, Puppet, Chef and HP QC by integrating them into a heterogeneous automation platform. This allows DevOps members to continue working using the tools they are most comfortable with, while allowing IT the flexibility of tool neutrality which prevents processes from being held hostage to vendors.  Additionally, an automation platform notifies team members of where along the pipeline a release or change is so everyone knows what to expect and when.

Reliable DevOps

When an enterprise chooses to adopt DevOps principles in production environments for customer-facing apps, they need an automation platform that can meet the scale, rigors and compliance requirements of production seamlessly. Few are using open source tools in production. Automic surveyed 200 customers and asked, “Would you consider using open source tools for your production environment?” Less than 10% said yes. Ops teams tend to avoid using open source in the production environment.

A repeatable deployment pipeline logically gives us DevOps metrics by which to measure success, meaning the business can be reassured that their investment is increasing release velocity whilst maintaining reliability at scale. So automation brings reliability to the often daunting prospect of a DevOps transformation. Isn’t it time you crossed the chasm?