Monday, February 16, 2015

"From complete chaos to Octopus Deploy" Part 6: The hosting vendors

Introduction to this blog series

How do you automate the non-existing deployment routines of an organization with over 100 different customers, each having their own environments? How do you convince the leaders, developers and customers to give you the resources needed in order to automate everything?  Is it really possible to introduce a routine that works for everyone?

The hosting vendors

As I described in part 2 of this blog series, the first step in introducing Octopus Deploy to our organization was to set up several of our projects to be deployed automatically to our internal demo server. After seeing that the deployments worked as expected, we would start using Octopus Deploy towards our customer environments. Dealing with customer environments meant that we would have to start including the hosting vendors.

You might find it a bit risky to wait this long to involve the hosting vendors, what if they refused to let us use Octopus Deploy towards their environments? But I looked upon the challenge from a different perspective. By this time, we were actively using Octopus for about 5 of our projects (although only towards our internal demo server), meaning that approximately 8-10 of our consultants were using Octopus Deploy daily. There are strength in numbers, and I thought that 8-10 developers would have a greater chance of convincing the hosting vendors than me alone. Remember, we're dealing with over 30 hosting vendors, the list is quite long.

We started out with the ones we knew would be easy, the ones who always say yes and do everything we ask them. Before long, our Octopus server was connected to several test and production environments from a couple of different hosting vendors. Hooray!

I created a document titled "Octopus from a hosting vendors perspective" and asked the developers to distribute it to all the hosting vendors they were working with. All questions we received in return were included in the "Q&A" section of the document so others wouldn't need to ask the same questions. After reading this document, several more hosting vendors have us their thumbs up.

But now we had to deal with the large hosting vendors, the ones that are usually quite strict. The "head of customer relation management" at Epinova scheduled meetings with the largest ones where we showed them Octopus Deploy and described to them in detail how we wanted to use Octopus towards the customer environments they were hosting. Their main doubts were usually the same ones: Security and SLAs.

Security

There's nothing insecure about Octopus Deploy, all communication between the Octopus server and its tentacles are done over HTTPS, and we always restrict the port the tentacles are listening to our office IP-address. We got all our security arguments confirmed when one of our customers, a leading company on web security in Norway, accepted our use of Octopus after analyzing the product themselves. Since then, we simply tell our hosting vendors that X approved it, and they have nothing they can say.

SLAs

When it comes to SLAs, the hosting vendors were afraid that automatic deployments with Octopus Deploy would lead to more downtime. We explained to them that although we were automating the deployment processes, we would not automatically introduce continuous delivery to all our projects. The number of deployments per customer would stay the same as before, the deployments would just be faster and less error prone. In consequence, it would in fact lead to less downtime.

Some of the SLAs contain clauses stating that the hosting vendor should be notified when a deploy is done and that monitoring of the applications should be turned off beforehand. The hosting vendor has had difficulties enforcing these rules as develops tend to forget them when they're in a rush. So the hosting vendors were quite excited when we told them that we can automate this as part of the process as well in Octopus Deploy.

At the time of writing, not a single hosting vendor has forbid us from using Octopus Deploy. Only one has demanded we use polling tentacles, the rest have allowed listening tentacles. In my eyes, this is a great success and to be honest: I had expected a lot more resistance than this. Stay tuned for tomorrows post: Load balancing

No comments:

Post a Comment