Month: December 2017

I heard that statement from Greg Ferro (@etherealmind) in a podcast a few weeks back.

I have to admit, I was a bit surprised and had a look at Greg’s tweets and posts, while finishing up the podcast.

Of course, the catchphrase is aimed at shocking, but it is quite well defended, and I have to agree, to some point with Greg on that.

Let me try to explain Greg’s point, as far as I have understood it.

 

The IaaS/PaaS platforms, and some of the SaaS ones, are aimed at providing you with on the shelf functionalities and apps, to develop your product quicker. And also to let you focus on your own business, rather than building every expertise needed out there to support your business. However, there are some underlying truths, and even drawbacks :

1. When you are using someone else’s “product”, you are tied to what this company will do with it. For example, if you were not a Citrix shop, and wanted to use Microsoft Remote Desktop on Azure… you are stuck as MS has discontinued RDS support on Azure, in favor of Citrix. To be a little less extreme, you will have to follow the lifecycle of the product you are using in the cloud, whether it matches with your own priorities and planning. IF you stay on-premises, even with a commercial product, you can still keep an old version, admittedly without support at some point in time. If you build you own solution… then you’re the boss!
2. The cloud services are aimed at being up and running in minutes, which helps  young companies and startups focus their meager resources on their business. And that’s good! Do you imagine starting a company today and having to setup all of your messaging/communication/office/email solution during a few weeks before being able to work for real? Of course not! You’ll probably start on Gapps, or Office 365 in a few minutes. It’s the same if you start building a software solution, IoT for example. Will you write every service you need from the ground up? Probably not. You’ll start with PaaS building blocks to manage the message queueing and device authentication. Nevertheless, as your product gains traction, and your needs become very specific, you will surely start to build your own services, to match your needs exactly.
3. And last but not least… the cloud companies are here to make money. Which means, at a point in time, it will not be profitable for you to use their services, rather than build your own.

 

There might be some other drawbacks, but I would like to point out a few advantages of cloud services, even on the long term.

1. Are you ready to invest the kind of money these companies invested in building their services and infrastructure? Granted, you might not need their level of coverage (geography, breadth of services etc.).
2. Are you ready to make some long term plans and commitments? You need them if you want to invest and build those services yourself
3. You might be a large, rich company, but if you want to start a new product/project, cloud services may still be a good solution, until you’ve validated that long term plan.

 

Say you’re building a video streaming service. You would start using AWS or Azure to support all of your services (backend, storage, interface, CDN etc.) But the cloud providers have built their services to satisfy the broader spectrum, and they may not be able to deliver exactly what you need. When your services are more popular, you will start building your own CDN, or supplement the one you have with a specific caching infrastructure, hosted directly within the ISP infrastructure. Yes, this is Netflix 😀

 

Any thoughts on that?

I already posted about this event a few weeks ago, with a focus around my experience and the organization : https://cloudinthealps.mandin.net/2017/11/03/velocity-london-2017/

This time, I would like to share a short summary of what I have learned during these 4 days.
The first two days were a Kubernetes training, so nothing very specific here. I learnt a lot about Kubernetes, which is to be expected 🙂

During the two conference days, I attended the keynotes, and several sessions.
The keynotes are difficult to sum up, as they were very different, and each was a succession of short talks. I attended several large-scale conferences in the past, and that was the first time that I felt that the speakers were really on the edge of research and technology. They were not specifically here to sell us their new product, but to share where their work was headed, what the outcomes could be etc.
They broached subjects ranging from bio-software to chaos engineering, from blockchain to edge computing. Some talks were really oriented toward IT & DevOps, and some were bringing a completely different view on our world.
Overall, it felt energizing to hear some many brilliant minds talk about what is mostly our future!The sessions were a bit more down to earth and provided with data, content and feedbacks that would bring us some changes back home. I was surprised to have most sessions concentrate on general information and feedback, and not so much on specific tools and solutions. I expected more sessions from the toolchains for DevOps (Chef, Puppet, Gitlab, Sensu and so on). Actually, even when the session were presented by these software companies (Datadog, Yahoo, Bitly, Puppet, PagerDuty) they never sold their product. However they used their experience and data to provide very useful insights and feedbacks.
What I brought back could be split into two categories : short term improvements/decisions that could be implemented as soon as I got back (which I did partly), and trends that would have to be thought about and analyzed, and then maybe crafted into a new offer or approach.
In the first category :
• Blameless post-mortems. A lot of data analyzed, with one takeout for us : keep the story focused and short. If you do not have anything to add apart from the basic timeline… maybe you’re not the right team to handle the post-mortem 🙂
• Solving overmonitoring and alert fatigue. This talk was a gamechanger for me. What Kishore Jalleda (https://twitter.com/KishoreJalleda) stated was this : you may stop monitoring applications and services that are not respectful. For example, if you get more than X alerts everyday from an application, you may go to the owner of the application and say “as you are generating too much noise, we will disable monitoring for a moment, until the situation comes back to something that is manageable by the 24*7 team” Of course you have to help the product team get back on track and identify what is monitoring and what is alerting (https://cloudinthealps.mandin.net/2017/05/12/monitoring-and-alerting/). And you need top management support before you go and apply that 🙂
• On the same topic, a session about monitoring containers came down to the same issue : how do you monitor the health of your application? Track the data 🙂

The second group covered mostly higher level topics, on how to organize your teams and company for successful DevOps transformation. I noted an ever spreading use of the term “SRE”, which I would qualify of misused most of the time. At least SRE seems now to qualify any team/engineer in charge of running your infrastructure.
Another trend, in terms of organization, was the model based on this famous SRE team, to provide tooling and best practices for each DevOps/Feature/Product team. I’ll probably post at length sometime later.