Getting your head in the cloud

Understanding the developer’s new worklife in the Cloud

Coman Hamilton
Cloud image via Shutterstock

We spoke to Cloud and SaaS-man Maarten Balliauw about the major adjustments developers and enterprises make when moving from on-premise to cloud.

JAXenter: Why is on-premise software suffering from competition in the cloud?

Maarten Balliauw: One of the main reasons on-premise software is suffering from competition in the cloud is that on-premise software is typically patched only whenever there’s a new release. So whenever I purchase a version of the software I either have to pay to be able to upgrade the licence whenever a new release is out. Or I have to at least wait until that new release fixes bugs or potential issues that are arising in that software.

Another reason is that developers and users of that software maybe blocked. Maybe the billing software (or whatever software they’re using) is stopping them from doing their work efficiently. They want things to go smoothly when they’re actually working on that thing. So one of the way people solve this is by unlocking themselves and switching to a SaaS somewhere online; enter their email, pick a password and just start using a better version of the software that suits their needs.

Shorter feedback loops are often talked of as another advantage of SaaS…

So from a vendor’s perspective, if you have a release every two years for on-premise software, you have a longer feedback loop with your customers – why? Because you can only release it every two years and you don’t get immediate feedback to the changes you’ve done. So maybe some customer asks you for a new feature in that software. But you’ll only be able to ship to your broad amount of customers every two years, because that’s your release cycle. Ideally you want to be able to ship the new change or feature and have people use it immediately after you ship it to your SaaS, for example. Then you can get feedback on whether this feedback is good, does it work in other scenarios and so on. So from a vendor perspective, or a company that’s building it’s own SaaS, that’s a really important thing. Again, opposed to on-premise software.

One other thing is that as a developer (or someone building something), you want to have shorter feedback loops. So if you’re a developer and you need a database environment, typically in large organisations you would go to your IT department, ask for a database server, and if you’re lucky you can get it in a day to a week. If you’re not that lucky (and I’ve been at such companies), it takes a month or even half a year to get that database server. It blocks your work that you don’t get immediate feedback on the fact that that database server is there, and your code can actually run against that database server. So even if it takes a day, that’s still a very long feedback cycle for an optimal development flow.

SEE ALSO: F*** off as a Service

Another example would be if you need to run tests against your software. Ideally you would want those tests to run immediately. You don’t want to have to wait until some other team runs the tests for you and then sends you an email with the summary of whatever was discovered in those tests. You want to just commit your code, make sure it’s built somewhere and within a few seconds or minutes, you want to get a response and see if your change did something good or bad.

Automated processes sound tempting – but what are the risks?

Automated processes basically help you shorten that feedback loop that you want as a developer. So I just gave the example of unit tests. But maybe you’re building a SaaS, you might have several services. Maybe you want to automate the deployment of that thing to be able to run functional tests or integration tests on that thing as well. And you can do that and I think you have to do that to reduce that feedback loop. Now, an important thing, as developers sometimes we want to automate things too much, because…we’re developers, and we like things to be beautiful and structured.

But the automation in the deployment of that thing is just a tool to give you a quicker feedback on the stuff that you’re actually building. So I think even a quick and dirty approach there is a very good thing because it reduces the time required for the feedback loop, while you’re still not spending too much time on automating stuff. But in the end I think you really should automate.

What benefits does the cloud bring to DevOps? And what are the challenges in on-premise situations?

The cloud brings lots of benefits to DevOps. One of them is that you can basically automate your entire environment by using many of the APIs available. So on Amazon you can host your Docker instances. On Azure there’s an API where you can basically describe what your surface should look like, what kind of server you need, how much RAM it should have, what IP addresses should be there, should it set up a VPN connection to your network, and so on. So by using cloud services for doing that, you can basically just script your entire environment and have it running.

“The difference is when you want to do it continuously”

Now, one would argue you can also do that on-premise. And that’s correct. The main difference comes when you want to do that a lot of times and continuously. So imagine you’re building software and you’re working with a concept called feature branching, where every feature is developed in a difference branch of the source codes – maybe you want to spin up an environment for every branch of the source codes. But also maybe your next release is 50 branches, which in this case would mean you need your entire environment 50 times – just to be able to test and host an environment.

In the cloud you can do that very quickly – you can just pay for it and can start using it. If you want to do that on premise, you have to have the capacity to be able to host 50 environments for that. And again, you can probably do that, but those 50 environments (or the capacity to be able to run that) will always be there, and you’re paying for that environment. Whereas in the cloud, even if that feature branch is very short-lived (like say a week), you can rent that capacity for a week and then give it back to the cloud so you’re no longer paying for it.

During your recent Webinale session, you spoke about how artificial constraints were slowing down the development process. Can you tell us how this happens?

Developers work best when they are in ‘the zone’, or have their flow. Probably as a developer you’ve experienced this. You come into the office, you grab yourself a coffee, you start working and all of a sudden it’s lunchtime and your coffee is still there… cold, obviously. But you didn’t realise this amount of time has passed. That’s being in ‘the zone’. And that’s a very important thing because you don’t have to park your thought train for questions and interruptions and so on. So by reducing artificial constraints, that are typically in every organisation, you can get your developers more in the zone.

Like for example, one artificial constraint could be that you need to use a specific tool to do some task. Why is that rule there? In a lot of companies, if you start asking that question, nobody will be able to answer you. Or the answers will be “Because that guy said we have to.” If you talk to that guy, he’ll just be like “You have to use that tool.” No valid reason, but just because he’s a manager – and that constraint is there. It could be a tool, a process, whatever.

But the problem is, if you have a frustrating tool to do that, your thought train (or your being in ‘the zone’) sometimes gets interrupted by having to either work around that thing or wait for an hour to use that tool and finish. So you’re out of the zone, and have to recover from that interruption. And artificial constraints typically bring more interruptions to a developers thought train.

What does an enterprise IT team need to think about before switching to a cloud approach?

I think obviously getting people familiar with the cloud platform is one of the most important things. First technically: so knowing what this platform support, how can I do things, what are the caveats… maybe if I transport this workload from my datacentre to the cloud it won’t work, so you have to familiarise yourself with those things.

SEE ALSO: How DevOps is forcing developers to take on more responsibilities

Then there’s the billing level. Since you pay for use: in your own environment you can sort of deduct what your environment is costing by calculating power consumption, the price of the server, connectivity, all that. In a cloud scenario there’s various pricing models related to the type of service that you’re using. So for example just to how a virtual machine, you may have to pay for storage, you may have to pay for bandwidth, you may have to pay for the time you’re using this thing, and so on. And all those things effectively influence the price that you’re paying at the end of the month. So you want to familiarise yourself with that just to avoid nasty surprises on your monthly bill.

And then there’s another thing you want to look into, which is compliance. Maybe your company doesn’t want specific data to go beyond the walls of the company. Maybe your government says your data cannot leave the country, or should stay in your own basement, or should be in a datacentre that is this amount of kilometres from the other datacentre. So you also want to look into those things to make sure that you’re compliant with everything that you’re doing and not shooting yourself in the foot (either technically, billing-wise or compliance-wise).

Coman Hamilton
Coman was Editor of at S&S Media Group. He has a master's degree in cultural studies and has written and edited content for numerous news, tech and culture websites and magazines, as well as several ad agencies.

Inline Feedbacks
View all comments