Mathew Morrey-Clark, head of engineering at Man Group and panellists at our recent Cloud Native: Blessing or SRE curse? event, shared his views on the most popular questions asked on the night.
Are there any areas that big cloud providers need to improve in their offering to make themselves more accessible to start-ups looking to go Native?
In the usual way of such things I did think more on this after the event! So, as I said AWS need to work on their developer experience; it still feels a lot like a platform targeted at the infrastructure people. Also, they need to start supporting more industry-wide systems in a PaaS fashion instead of just building their own. They were really late to the game with hosting Kubernetes and it felt like it was a very half-hearted effort and AFAIK there’s still no hosted Kafka. By rolling their own they put people off who are worried about vendor lock-in and they make it harder for people to migrate existing applications to them.
For Azure, I confess less experience but from talking to people on the infrastructure side it seems to be the opposite problem: AWS is so much more mature in terms of things like Availability Zones and the configuration of that side of things that even if developers are crying out for Azure, often the cloud-migration process is led by infrastructure and they want AWS.
How do you solve conflicts that could inevitably arise between software development and IT operations?
More teams or tools will never solve the underlying problems if both teams are motivated by different things. As for how you change a culture like this… I wish I had the answer to that, but it’s different in every context.
How do you solve local development setup when you start using a lot of cloud specific services?
It depends on what cloud specific services you are using but a lot of them offer SDKs that either let you simulate things on your local machine, or allow you to deploy directly from your local machine and then connect to services running in the cloud. Azure is particularly good on this front. There’s no one-size fits all answer, and there’s no denying that it does add effort to get all this set up compared to the good ol’ days of just running the app on your local machine, and this is just part of the pros-and-cons trade off of a lot of modern application development like micro-services, PaaS, cloud, etc.
What’s your view on quality verses speed in the early days of any project?
That it’s not necessarily a trade off at all. People assume that quality and speed is a zero-sum game, but actually it doesn’t have to be. Having said that, I’ll give some more concrete advice:
- Take a bit of time to understand which bits will be hard to change later; spend time on those parts up front.
- For the bits that will be easier to change later strive to make your code replaceable rather than maintainable. A architecture where you can throw in a quick and dirty bit of code that does the job for now, then later write something better and just swap them out will be orders of magnitude easier to improve than one where you are trying to turn the old one into the improved one while it’s still in place.
- To enable the point above, spend time and effort getting the boundaries and the interfaces at those boundaries right.
For all of the above make sensible assumptions about growth. There is no point throwing something together that will collapse at your first signs of success, but equally you don’t need to plan for Facebook-level scale yet.
What does kubernetes give me that serverless doesn’t from a business or end user perspective?
By Serverless, I’m assuming we’re talking FaaS? If so…
From an end-user perspective, mostly performance; cold-start times are a serious problem in some contexts; having hot containers ready to serve requests will give far better performance
From a business perspective, mostly cost in a lot of cases. Just like shifting a load of VMs to the cloud will actually increase your costs compared to running your own servers, just shifting compute from long-running containers to FaaS will probably do this too. Where FaaS shines is when you have very volatile usage where you might go from 0 instances running to 1000 for a few minutes, then back to 0 for hours; for a more consistent workload it will almost always be cheaper to run a small number of persistent containers.
It’s also worth mentioning “better management of complex systems”; this is technical but a direct result of this will almost certainly be more bugs, which is definitely an end-user concern!
So, both cloud native and on prem can be successes or failures. Is it just a case of picking which one you have the most skill with or is there more to it?
Some things are only really possible in the cloud and if you need those, then there’s certainly more to it. When this isn’t the case, and there’s no real compelling reason either way from a technical perspective then it’s really a case of costs and time horizons. If you think that it will be cheaper in the cloud (and it’s not just the Capex of the servers – don’t underestimate the cost of having a team to look after your data centre and run, maintain, and upgrade your own Kubernetes cluster), then it will probably work out cheaper over a few years to upskill your team and look to move as your current hardware reaches end of life. Looking at the skillset of your team when choosing something is definitely a factor, but if the time horizon is long enough then you shouldn’t let that be the only factor: any good team can upskill itself.
How do you deal with a situation when you spend months to build a service and once you finish, Amazon makes it a managed service?
That can happen and sometimes there is just no way of avoiding it. However, a few things that might help:
- If another cloud provider already offers it as a service, go with them. It’s better to pick a service and be agnostic about a provider than pick a provider that doesn’t actually provide the services you need.
- If you are already tied into Amazon, consider an alternative that is already offered. If you want to use Kafka, even if you really like it, it might be more sensible to use Kinesis or something rather than roll your own Kafka.
- Talk to Amazon. I’ve been in just this situation, but by having regular catch-ups with our account manager we discovered that they were already quite far along with providing what we were looking for. We changed our plans based on this and delayed the work until they’d released it. This can bite you when they are six months late with delivery of course, and they unexpectedly only roll it out in the US for the first year or something!
Is cloud native the only way when your application has known increased traffic? (It would be too expensive to support peak traffic at any time)
I assume this question is asking “would it be too expensive at any point in the future to own a data centre capable of supporting peak traffic?” I’d argue that if this is true then the cloud won’t help – Facebook run their own data centres remember ;). However, if I stop being facetious then the answer is probably “yes”, though it is worth bearing in mind that there are possibilities with things like a hybrid model, where you handle base load yourself and somehow farm peak out to a cloud provider.
Does every tech company become more efficient after adopting cloud?
Define “tech company”. These days more and more companies are becoming more and more tech focused. Some companies are clearly “tech companies”; some are clearly not. But the majority these days lie somewhere on a continuum. You could even argue that companies like Google are actually advertising companies if you look at revenues!
Having said that, the short answer is “no – context is king… but I would wager that most do”.