Using the Cloud can greatly enhance your business efficiency, however, it’s worth noting that switching to the Cloud can also simply change the types of problems you face, rather than eliminating them entirely. In this episode, Zoe Cunningham shares some insight into the basics of why, when and how we should be using Cloud. Zoe is joined by Softwire Senior Consultant, Daniel Waters and DevOps Lead, Usman Iqbal.
You can read the full transcript here:
Zoe Cunningham: Hello, welcome to Softwire Techtalks, I’m Zoe Cunningham.
I am delighted to have Usman and Dan, on the show with me, Usman, and, Dan, please can I ask you to introduce yourselves, tell us what you do at Softwire, and also an interesting fact about yourself.
Daniel: Hello, my name is Daniel. I am a Senior Consultant at Softwire. I have been at Softwire coming up to eight years. It’s pretty much my eight-year anniversary actually. I have done pretty much every single role that you can do at Softwire, I think, apart from all the ones that you’ve done, Zoe. I totally forgot to write an interesting fact.
Zoe: It being your eight-year anniversary is quite an interesting fact. I think you could have just coasted on that one and you would have been fine.
Daniel: Yes, I could.
Daniel: Thank you.
Usman: Hi, my name’s Usman. I am also a Senior Consultant/DevOps Lead in Software. I joined actually just a year before Dan, so I’m coming up to my ninth-year anniversary.
Zoe: I’ll take your eight years.
Usman: I’ll raise you up.
Zoe: Oh, congratulations to you too, Usman.
Daniel: How about you, Zoe?
Zoe: Oh, so I joined in August – obviously we do have lots of people who join in August – in the Year 2000. For me, it’s going to be my 20 year anniversary this year.
Daniel: Oh, congratulations.
Zoe: Bit scary. Thank you very much. In today’s episode, we’re going to talk about the cloud. Cloud computing or ‘the cloud’ refers to the on-demand availability of computer system resources, particularly data storage and computing power without any direct active management by the user. Or to put it another way, the cloud usually refers to using remote data centers available to many users over the internet, as opposed to your own dedicated servers that no one else can access. Using the cloud can greatly enhance your business efficiency, but it’s worth noting that switching to the cloud can also simply change the types of problems that you face rather than eliminating problems entirely.
In this introductory episode, Dan and Usman are going to talk us through the basics of why, when, and how we should be using the cloud. Welcome to the show. Tell us why is now a great time to migrate to the cloud as opposed to say 5, 10 years ago.
Daniel: Sure. I think the main thing to say is that the cloud has become mainstream. It has become, I would say, the typical way to build software and modern software applications. If you were looking at something maybe five years ago, you might have considered using the cloud for your software, for your deployment, but you’d have been a little bit on the cutting edge. I think you’d have been venturing slightly into the unknown at that point. We certainly did cloud projects five years ago, and we have seen the kind of changes that have happened in the past five years.
The maturity of all of the major cloud providers has just increased 10-fold, 20-fold, I don’t know, so far in the past few years. All of the big problems that you’re likely to encounter on a typical software project are now just solved. For example, we have orchestration platforms, we have deployment methods, we have huge amounts of processes that are designed to help you run software in the cloud, that simply just weren’t there in the past.
Usman: Just to add to that, there’s a lot more innovation going on in the cloud these days as well, whilst typically, five years ago, you were looking at just perhaps a database, perhaps some VMs. You’ve now got GPU acceleration, serverless architectures, data warehousing up in the cloud things as well. They’re just adding more and more stuff. It’s very much the place where it’s at if you want to do something a bit different or a bit more innovative.
Zoe: So we’re just getting to the point where it’s much more fully featured and it’s not cutting edge anymore. It’s not like you’re going into the cloud and no one’s been there before. It’s like, “Okay, it’s safe now. You can go”?
Daniel: Yes, the risk has disappeared to some extent. For example, we’ve seen recently a huge amount of increase in the– just the number of resources online to support our deployment. People that work in software will have experience. It will become part of the normal software development process. Instead of saying, “I’m going to deliver this software and learn about the cloud.” The second part has just totally disappeared in the past few years. It’s just part of the standard development process.
Zoe: Okay, so that answers, “Why now?” What kind of applications would a tech team want to migrate to the cloud? Could you maybe give me some examples or some features of the kind of applications that it would make sense to move? When people have– they’re using these applications already, but they want to migrate them to the cloud.
Usman: When you start any migration job, it’s very tempting to find the biggest baddest thing and throw it on there and see what happens. That makes sense. It’s much more exciting, but if this is your first time, then it’s also quite a risky maneuver. You’re better off starting with something which is well-defined, ideally not legacy because legacy usually means last requirements. Something fairly newish, small, well-defined. Something that if it falls over, it’s not the end of the world. Then you can use that as an opportunity to learn and find out what the right fit is for you.
As Daniel said, there are lots of different orchestration platforms and ways in which you can do it, which means there’s a lot of competition and different ideologies. Finding the one that fits for you and your business is really important. It’s a good thing to get right, as early as possible.
Daniel: Developing that kind of internal knowledge is very important, as Usman said. A good example of the kind of thing you might want to move to the cloud-first might be something like a small internal application, something that isn’t customer-facing, something that is just used by a few people within your business, who know their domain, who know all of the possible error routes through your application, someone who knows it inside out. That might be a really good fit for your first thing to deploy to the cloud. You can consider that to be, “I’m not learning about my application. I’m not learning about all my customers. I’m simply using this to learn about how my company and my staff can work with a cloud provider.”
Zoe: Great. Then you can move on from that to migrating more applications or bigger applications?
Daniel: Exactly. You’ll learn patterns, you’ll learn the kinds of things that your business cares about. As you learn these things, you can apply those principles to more and more complex applications as more of your business becomes part of the cloud, absolutely.
Zoe: Fabulous. What are the options for sourcing your cloud?
Usman: You can take your pick really. Everyone’s heard of the big names, Amazon Web Services, Microsoft Azure, Google Cloud Platform, they kind of do everything I would say. They definitely have all the bread and butter stuff like databases, VMs, serverless, containers. There’s a bit more vendor lock-in, as you can imagine because you’re doing it the way they want to, not entirely. With things like, for example, S3, that’s become a de-facto standard. You can use that in multiple places. It all depends on what you want to do, but that’s certainly one place to start.
There are alternatives. For example, one of my favorite ways to go is with OpenStack, which is an open-source. It’s essentially a set of software projects that allow you to run your own cloud. This was written by Rackspace and NASA back in the day, Rackspace still use it heavily for their cloud offerings and other companies do as well, including ones like OVH. You can either use an open-source provider, or you could just do it yourself. It all depends on how big your company is and what gains you get for it.
Daniel: One thing to point out is if you are going through one of the big players, they have different levels of maturity in different aspects of their services. Although most of them have effective parity of features across all of the things you might want to do, if you are looking to do something quite specific, it’s definitely worth checking, not just the billing price that you expect from each of these vendors, but also whether they are supporting these at use cases that you’re after. For example, we’ve got a lot of– our applications recently have started running containers. If you’re running something in Coobernetti’s, then Google Cloud Platform is kind of built natively around this in a way that AWS has only recently caught up with.
There’ll be lots of examples of this. In any particular cloud platform, you pick, there’ll be one area where they may be stronger, and one area where they may be weaker. It’s just bearing in mind, what exactly do I need from my provider? Have they got the appropriate level of support? Having said that most of them are feature-complete and often it will just come down to who’s offering me the best deal on my computing power.
Zoe: Fair enough. I learned a new word, what is the hybrid cloud?
Usman: Essentially, having your cake and eating it. In this case, you don’t have to move everything into the cloud if you don’t want to. There are definitely going to be examples where it could be a case of specialist hardware you have to work with, that just can’t be put in the cloud, or perhaps there are some requirements with your data. What it essentially means is you have a direct connection to, for example, AWS, and they have services for this, and you work with the cloud as if it was in your data center and vice versa. They talk to each other almost like a VPN connection.
Zoe: Right, so what you’re saying is, you don’t have to have everything in the cloud. You can have some things in the cloud, some things not in the cloud. Then you can set up this hybrid cloud so that they all work together?
Usman: Absolutely, and it’s a really good way to start moving things across. If you have, for example, a large estate that is essentially one or two big applications, you could move maybe the front end into the cloud and use the hybrid nature to keep other stuff within your internal network.
Daniel: The other aspect of this is that it can decouple the risk associated with a cloud move. If you have, for example, as Usman said, if you have specific data requirements, “I have to store my data within the UK,” or, “I have to have special encryption rest practices that I know work for my current application, but also I’d love to start using the cloud for my front end applications to access all of the scalability.” Or disaster recovery systems that are built into cloud platforms, you might say, “Okay, well, I can split my application layer into those two parts and continue to host one in my own server, which I trust and I’m happy with while taking advantage of the features for other areas of business which do not need that kind of protection layers around them.”
Zoe: Okay, super. We’ve isolated, a small application, a small non-critical application that we’re going to trial, moving to the cloud. What kind of things do you need to consider when you start migrating your applications to the cloud?
Daniel: As we said earlier, choosing a cloud provider is a really serious consideration that you should have. As I said, each provider will do things in a slightly different way. Choosing a cloud provider, obviously, it’s a key part of your cloud migration strategy, but in reality, that is going to vary from business to business. You might choose Azure because you’re based on Microsoft. You might use AWS because you have and you want to use Lambda. There are lots of reasons why you might choose a particular cloud provider, but that decision is going to form the basis of every subsequent decision that you make.
Zoe: So you don’t want to be changing your mind later on?
Daniel: I think you want to consider whether you’ll be changing your mind later on. There are ways that you could design your system so that it was possible. You might say, “I don’t really care. I just want this thing to be done,” in which case, yes, you don’t need to worry about those things so much. That’s another key thing, is looking at your internal staff. You’ll need a different set of skills to manage cloud workloads compared to bare metal. People will need a bit of time to retrain. Often, the concepts will be similar, but they’ll just be named differently or they’ll just have slightly different interfaces or ways of working within AWS, as you might if you run your own server, for example.
You’ll need to consider time for your staff to get used to the platform you’ve pitched, and you may even need some external assistance to help you bridge the gap between my current operations team that I have right now and the operations team that I’d love to have in the future.
Zoe: Got it, we’re happy from a practical point of view. What do we need to worry about from a compliance point of view?
Usman: Server into the cloud means your data is now somewhere else. That’s quite a big issue, especially with– some of the gains of the cloud are as Dan mentioned disaster recovery through things like different regions and availability zones. If the data center suffers an outage, your stuff is still running, but that might mean then that you’ve got stuff running outside of the UK or outside of the EU. If you’ve got GDPR concerns, that’s a big question. There’s also things about encryption at rest, audibility. There are all these kinds of things, which are, they’ve kind of already been thought about in all of these cloud platforms, so there are ways to do things. In AWS, you’ve got IAM management. You do have the ability to encrypt things at rest.
Zoe: Could you just run me through what those things are? What is IAM management and what is encryption at rest?
Usman: IAM is the name for the user management system. I believe it’s a name shared by other providers, I think it’s a general name. It sorts out things like access control lists, permissions, user and service accounts, what people essentially do when they access the control panels. Encryption at rest is for your data. When it’s sitting on the desk or the SSD, it’s all encrypted. If someone went into the data center and nabbed the disk, they still wouldn’t be able to do anything with it.
Zoe: Got it, okay. So the whole point of the cloud is you don’t know exactly which box it’s sitting on. The point is whichever box it’s sitting on, if someone goes and steals the hard drive, then it’s encrypted?
Usman: Yes. It also means like for example, AWS staff can’t see your data and stuff like that. Again, it’s with other cloud providers. I just like saying AWS I think. It just means then that no one can be bribed. To be honest, I think most workloads we’re going to be working with, there’s probably nothing in there like military secrets, but it’s still nice to know that your data is safe. There are a lot of companies that do require that.
Zoe: Well I think it’s a good point, isn’t it? Whenever you’ve got new people who aren’t even on your own payroll, right? People who now have access to something that is important such as your data, if you think about managing your own data warehouse, you would have strict controls over who could physically go in the building and what they could see and how that works. Actually, it’s a really good point that you need to rethink all of that from a cloud perspective.
Then again, back to the point of, from the first question, that because we’re coming to this now when the cloud is a mature system to use, then people have thought about these problems already. It’s finding the ways to do it and just making sure that you’re doing that.
Usman: It is worth pointing out that they’re not perfect. Generally speaking, even though you’re using one big pool of hardware with millions of other people, they’re very good at segregating what’s yours and what’s not yours and keeping everything apart. If you do have that data warehouse, you can be quite comfortable in the fact that whoever you say is allowed to access it can access it and nobody else.
Daniel: The other thing that’s possibly worth considering from a compliant point of view, is internal company policies. As we’ve mentioned, these kinds of moves can often generate– If they don’t generate risks themselves, they can certainly generate the idea of risk. Especially if your company is not one that’s built on technology and your data can be one of your most important assets in this case. You might well have a legal team that wants to have a say, you might well have an operations team that wants to have a say.
I suppose you might want to consider building a bit of a business case for why it’s worth moving to the cloud and why it’s worth, perhaps, re-writing some of those internal company policies, which might say, “We store our data in our head office in the basement,” I don’t know. You’ll need to potentially go forward into your company and start to try and change that culture a little bit as well. You could see non-compliances as the legal side, or you could see it as a, “I need to change what is compliant.”
Zoe: That’s very, very interesting because actually, all policies are made based on the situation at the time. No one knows that someone’s going to invent cloud computing and everything will be done differently. You could well have written contracts with all kinds of different stakeholders, maybe even with your ultimate customers saying, “You know that when you use our service you’re secure because we have our data in our head office.”
Daniel: Absolutely. We’ve worked with customers who have had that exact problem of, “I want to store my assets outside of my head office now. I want to receive them and put them in the cloud because that’s where we keep our data now, but I have all these legacy contracts that I’ll need to go back through to make sure that we aren’t suddenly violating the terms of those contracts.” There are other issues which, which can kind of provide a little bit of drag on the process that are just worth considering upfront, “Do I have any of these kinds of scenarios?”
Zoe: Is it only data that you’re likely to have contracts around, or could there be anything else about the infrastructure? Presumably, it is mostly data is that you need to consider?
Daniel: I would say it’s mostly persistent storage. Although there are occasions when you might want to compute certain results. For example, in a medical setting where you might say, “I need the power of the cloud in order to run,” maybe some artificial intelligence results against some scans, and that needs to be done in high volumes. It needs to be done in a platform that really can’t exist in a hospital. There are other considerations like that, where you might say, “I need this to be done in the cloud.” I guess data is still the problem. The idea of leaking data is still the problem, but there are security practices around what can run and where that you can also put in place for the general application running as well as data storage, yes.
Zoe: Sure. Where you store your data and where you process your data, right?
Daniel: Exactly, exactly.
Zoe: We’ve talked about migration. What if you’re building a new application? I appreciate this is quite an open ended question, but should you build your new application in the cloud?
Usman: To me, the answer is almost definitely yes. It does depend entirely on what you mean by a new application. If you’re connecting to an existing database, which is on-premise, then it’s still possible through the magic of hybrid cloud and stuff. Generally, if you like the idea of moving to the cloud, it’s just a great opportunity to start thinking cloud because as we’ve discussed earlier, it does change the way in which you do things in terms of having a different way in which operations run and other similar things.
There are lots of different things you can do within your application that make it more cloud-ready. For example, in Azure, you might start connecting it to Application Insights, so you can get more metrics on how things are going. If you were going to do this on-premise, that would be pointless.
Zoe: I think what you’re saying is if you are eventually thinking about running some applications in the cloud, by building a new application in the cloud, rather than building it somewhere else and migrating it later, you’re better able to take advantage of the features of the cloud because you can do so from the start and you can build it in from the start.
Usman: Yes, exactly.
Daniel: In answer to your original question, I also attempted to say, yes, Zoe, as a flat answer. For the exact reason that you said, I feel like there’s an extent to which the operating model of running an application in the cloud, runs both ways. You obviously have to design your software so that it takes advantage of these features. The cloud constraints you in some ways, but also it forces you to consider some of the boundaries of your application that may be traditionally you wouldn’t have done. As an example, AWS has managed caching. For a platform, something like Memcached, you can just spin up an instance and pay for it. In the past, you might have said something like, “I need to run one of these instances. I need to make sure it’s up. I need to make sure that I can connect to it and that it runs on the same box as my main server,” a whole bunch of considerations that might even have got you to the point where you say, “It’s not worth it.” Whereas now you could think about caching in a totally different way and say something like, “I know I can access this on-demand. I know I only need to pay for the smaller server until I feel comfortable going up to– that my use is going to be high enough to go to the next level.”
That kind of little decision that you can make at the start of building a new application can be really fruitful later on. It can absolutely change the structure of your application. It can make it a lot cleaner. It can preserve the business logic in your code and put all of the kind of external plumbing into the cloud so that what you’re left with is a much cleaner and simpler application to actually maintain in the future.
The reason it’s not a total, “Yes” is because I think there are still occasions where some of those concerns over data and potentially even cost can just outweigh the benefits that you would get. Especially in the case of a super simple application that you’re really only running every now and then, you don’t have any scalability requirements, you don’t have many users.
I’m thinking, especially, of Softwire as a company, we have quite a lot of capability to run our own internal applications on our own servers. For some of those, it just doesn’t make sense to spend money hosting this in the cloud where we can do it for free in-house. Not everyone has these capabilities. We’re in quite a position where we do, a quite nice position where we do, but there are still occasions where you might turn around and say, “I don’t need this to be in the cloud.” Having said that, I think it’s still worth building it as if it was going to be in the cloud to gain the advantage of all of that kind of architectural thought processes that you might have when deploying into the cloud.
Zoe: Essentially the message I’m getting by reading between the lines is that the cloud is here to stay now and going forwards more and more, applications will be built and hosted in the cloud and taking advantage of these cloud-native features, so it’s worth investing and starting that process of either migrating or building new applications in the cloud.
Daniel: Yes, definitely.
Zoe: Just finally then, as an organization, if you’re thinking about essentially changing how you work and how your technology support works and becoming a cloud-enabled team or organization, what impact is that going to have on the people who work for you already?
Usman: There’s quite a paradigm shift in terms of the different operating models. Before, you’ll have an ops team that know how to get their hands dirty with fixing hardware and getting all these kinds of bits and pieces up and running. You’re going to have a lot less need for that. You’re going to need more orchestration, more understanding of how the cloud works, and how to understand the language of your cloud provider. Within that, a lot of stuff has, for example, code and other similar ways in which you build out that infrastructure. If you’re going to seriously use the cloud, you definitely want to look at some of them which means learning more applications, learning how other domain-specific languages work. Let’s say it’s a paradigm shift in terms of what you are used to doing is now quite transformed into something else.
Daniel: It sounds like a lot to learn, but there’s also a lot to forget as well. There are areas of training for your operations team that you probably will just no longer need. For example, you’re not, you’re suddenly not constrained by operating system updates. You don’t need to bring down your own servers to patch the server so that you can do a new release. You’re suddenly not worried about installing new versions of software that support your application onto hardware that you control. To a certain extent, although there is a lot to learn, there’s also, it’s a replacement of a previous set of skills, as opposed to on top of a previous set of skills. Those things are probably still worth knowing to some extent, and you will still encounter various issues like that when running the cloud. As Usman said, you’re effectively configuring someone else’s software, as opposed to running your own hardware. The buck, kind of no longer stops with you. You are also a little bit dependent on a provider, albeit quite a stable provider, but you’re still dependent on a third-party provider for what could be key aspects of your business. If you’re of a mindset where you want to keep that control, then there’s another consideration there of how you would do so when operating within the cloud.
Zoe: On one hand, you’ve got someone else to do everything for you, but then, on the other hand, you’re then reliant on them.
Zoe: Oh, well, thank you so much, Dan, and, Usman, for that whistle-stop tour of the cloud. I feel like I learned a lot in a very short time. Thank you for listening. If you’re thinking of migrating to the cloud or starting a new project using cloud technology, then please listen out for our future podcasts where we’ll be going into some of these topics in more detail.