Month: July 2017

I may have skimmed that subject a few times before, but as I get to the end of the (Microsoft) year, and begin a new one, it feels right to reflect for a while on what got me where I am now.

The short version is : I got enough of cabling, servers, storage and operating systems, and wanted to move to something else, however related. Okay, that is VERY short. Allow me to develop that further.

I started working in IT about 15 years ago. I did my duties in user support, moved to network engineering and implementation. At the same time, I discovered the wonderful world of Microsoft training and certification, and got my first cert around 2003, quickly followed by an MCSE (yes, on Windows 2000!).

I switched back and forth between networking and systems engineering for several customers. I collected some knowledge along the way, mainly about hardware installation, cabling, storage and servers, but also about virtualization, networking, SAN. I continued my cert trip in parallel, maintaining my MCSE up to Windows 2016 and Azure. I also collected a few other certs : ITIL, Redhat RHCE (6 & 7), Vmware VCP & VCAP-DCD, Prince2 etc. I will say more about certification in a later article, keep in touch!

To complete the brush-up, I tried my hand at project management, as well as people management.

Let’s get to the point where it gets interesting. First time I heard about public cloud was at Tech-Ed Europe, probably in 2010. It was mostly limited to SQL server databases with many limitations. It was not really a hit for me. The subject kept reappearing : public cloud, private cloud, elastic computing, you’ve heard the talk.

There were actually two triggers to my “Frederi, meet Cloud” moment.

The first one was rather a long term evolution of my area of interest. After years spent working with the same company, and on the same software, I got to the point where I could understand the business side of my actions and responsibilities for our customers. It was a slow shift to a more end-user/application centric approach. This is where I try to push today : the major focus and metric is the end-user. If this user is not happy about his experience, then we (the whole team behind the software, from IT infrastructure to developers and designers) have failed. This is why I tend to ask the question early in the discussions : how is the application used? By who?

The second trigger was more of a “a-ha” moment, specifically about public cloud. In a previous job, I was in an outsourcing team, focused on infrastructure. We had a whole Services department, whose job was to design build and deliver custom software. We almost never had a project in common. Until once we had a developer on the phone, and we had the most common conversation  between dev and ops :

Dev : “we have built a php application for that customer, and he wants to know if we can host and operate it, and what the cost would be”

Ops (me) : “OK, tell me your exact need : OS, VM size, which web server, which version, how much disk space, a public IP etc?”

Dev : “I do not know that”

Ops : “in that case, I cannot give you an estimate. We can operate, but we need to know what”

Follows a few days of emails trying to get those details ironed out and try to write a proposal. Two weeks later, we had the same dev on the phone : “Drop it, the customer has already deployed in Azure by himself”.

That is when I realized that we, ops and infra, could not stay on the defense line and ask for what we knew best. We had to ask about the application itself, and we had to get into that “Azure” stuff.

And that’s how I ended up in Azure, and mostly PaaS oriented 😉

 

I know, there are tons of materials and training that will explain you how to select between SaaS and custom software.

I’ll summarize their usual points, but I wanted to add some details on how you might have to look at the full scope of cloud services : from Iaas, through PaaS, to Saas, and a detour through containers.

 

First the usual discussion, that have seen unfurl dozens of times : why choose SaaS over a custom/on-premises solution? You know the drill, right?

On one side, you have full control and can customize the solution. This means the software will be tailored to your exact needs, and you will control exactly what is done with it, how is updated, where data is stored, accessed, replicated, backed-up etc. You will know the exact setup of the deployment, which layer is connected to which other layer, how, where traffic goes, how each layer is protected, and replicated. You will handle failover, high-availability etc. In a few words : you will be the master in your own kingdom. Problem with that path : you are, mostly, on your own. All of these domains I just listed are your responsibility, and you have to have knowledge and skills to handle those. You might need to expand those skills to cover 24*7. You’ll need a strong IT team, in addition to a trained software team.

On the other side, you have SaaS : bright new, quick and easy. You set that up in a flash, connect the solution to your other enterprise software, create user accounts and voilà! No administrative overhead, the only skill you have to master is the configuration of the solution. You’ve seen the downside coming : you have absolutely no control over the software, its release cycle, the mechanisms in place to provide high-availability. Sometimes you have some control over your data, but it’s not obvious.

In the end it’s your call to choose the balance you need.

The cloud has integrated the same choices and solutions. You will have to decide whether you want to use IaaS, PaaS or SaaS. The basic triggers are the same, you choose the right balance between control, freedom and responsibility.

Read here a good explanation : https://docs.microsoft.com/fr-fr/azure/app-service-web/choose-web-site-cloud-service-vm

I  would like to add something to that horizon, something spicier, which could probably give you the best of each solution, provided you are ready to learn some new skills. We had the same discussion several times with our customers, revolving around the limitations of Azure App Service for some Java applications, its lack of control, and how moving from that to a full-blown IaaS virtual machines felt like dropping out of the cloud.

Here what we built with some of those customers. We wanted to provide them with the flexibility and ease of use of Azure App Service, tailored to their needs, without adding much IT admin overhead. We had already been running a Kubernetes cluster for our own internal needs for a while, and it was an easy leap to suggest that solution.

Kubernetes is becoming the leader in container orchestration, but you could choose any other solution (DCOS, Swarm etc.)

Here is a short list of the benefits the customer gained in that solution :

• Flexibility of the deployment and settings of the application, down to every Java VM option
• Scalability of an enterprise-ready container orchestration, based on a cloud platform that is reliable
• Ease of deployment : these are containers after all!

 

The only thing you have to keep in mind here is that someone has to learn and master containers and the orchestration layer for those. Kubernetes might not be the most accessible solution here, but it is, in my mind, the most mature and powerful.

 

One last word, for you sceptics who still believe that Microsoft and Open-source are still far from each other : try to make a new build of your software for containers using Visual Studio :

 

https://blogs.msdn.microsoft.com/jcorioland/2016/08/19/build-push-and-run-docker-images-with-visual-studio-team-services/