34:2 Agency in the cloud
In 2012 my agency used multiple providers on multiple platforms. We’d created a support nightmare for ourselves and we knew we needed to change how we delivered our services. This podcast unpacks our journey into the cloud and the lessons learned along the way.
In 2012 my agency used multiple providers on multiple platforms. We’d created a support nightmare for ourselves and we knew we needed to change how we delivered our services. This podcast unpacks our journey into the cloud and the lessons learned along the way.
We unpack:
- Our agency in 2012
- Where we are now in 2020
- What we realised we needed
- Our takeaways from the process
The key takeaways:
- Standardise
- Processes
- Interfaces
- Tools
- Automate
- Stacks
- Setups
- Deployment
- Tracking
- Backups
- Scalability
- Business continuity
- Backups
- Quick restore
- Server independent
- Document
- Processes
- Setup
- Support
- Configuration
Transcript
Welcome to the Agency Trailblazer Podcast. This is your host Lee. On today’s show I want to talk about Cloud Computing and we’re going to do this by jumping into a time machine and comparing where we were to where we are today. Now full disclosure, you are aware that Cloudways do sponsor this podcast, so my experience is going to be drawn from using the Cloudways platform. However that is not to discount or discredit any other third party providers. So all of the advice that I am going to share with you and the lessons learned can more than likely be applied to other providers as well. So don’t feel like you have to go for Cloudways. You can go with any provider who meets the way that your business run that matches your own processes and procedures. It’s important that you choose the provider that is right for you.
For us it’s been Cloudways, but for you that could be a different journey. However, please do listen to where we were, where we are now and pull out of that for you. Some of those lessons learned to see if you can improve your overall infrastructure. So let’s jump into that time machine visit where we were then fast forward to today to see where we are and then unpack the lessons that we have learned along the way. Now strapping, let’s go back to 2012 when I first launched Angled Crown, the idea behind angle crown was to take what I’d established in our agency and productize it. I joined a predominantly print agency and we’d moved from that world into a full service digital agency. And I don’t ascribe to full service as you know from previous podcasts, but we’d at least taken that journey and we’d hit a point where I was now predominantly doing administration rather than doing the code.
And I really missed the code. So I was freed to start Angled Crown as an agency that would support other agencies. And our focus was to build WordPress websites from the designs from design agencies and also manage hosting and so on and so forth. So if we look at the infrastructure that we had back then, I had multiple accounts with multiple hosting providers, some more on C panel, some more on Plesk and some more on just custom setups that I’d never really seen before and probably hated. This meant that I had to go to multiple places for support. We had to maintain multiple spreadsheets cause we were trying to work out where our clients were hosted, what their setup was, who was responsible as a company, what was the SLA of that particular company, what was our SLA with the client. It was a little bit of a, what made it worse as well is with all of these platforms, we were a slave to eight sched
We were not able to invest the funds to get dedicated service for our clients and our clients weren’t really willing to invest that sort of money either. So we were left using shared resources and that meant sites were not really performing as well as they could have. If on the other hand a client could afford their own dedicated server, then that would be pricey, but we’d often hit the limits of that service capacity very, very quickly. If you imagine as well, we have multiple separate websites on multiple separate hosts, multiple separate dedicated servers. Again, through multiple different providers. It was becoming a bit of a nightmare and we couldn’t scale so take a moment. Is any of this resonating with you? Do you have these problems in your agency right now because where we were was really frustrating. It made supporting our clients quite difficult.
It meant that we were often having to go to spreadsheets to find out where things were hosted. If we needed to move a site or start a brand new site. There was a lot of decisions that had to be made. We didn’t know which service provider to use if we needed to move the site. It was going to take a long time because there were no real tools. I mean, this is five years ago, a lot has changed, but there were no tools available to us. It was overall just a frustrating experience and when I wanted to document how things worked, I had to document the same process four or five times because we have different providers and had to use them in different ways. I mean one example of compatibility was where we would want to use SFTP to synchronise with sublime editor so that we could make a change and it automatically uploaded.
However, with one provider we could do that out of the box with sublime and yet with another provider we had to make sure that we had a certificate installed locally and we would have to document that process so that if we were using that particular provider, our developers knew how to interact with sublime, they knew how to interact with SFTP and all. They knew how to get it all set up as well from scratch. So this is multiple documentation, multiple headaches. It was no fun. Does it resonate anyone else having these problems? I would encourage you to pause and head on over to our Facebook group. That’s www.trailblazer.fm/group and come and let us know what your hosting woes are right now and I’m pretty sure I just said hosting. What are your hosting was let us know, I didn’t say www.trailblazer.fm/group
Alright, let’s jump back into that time machine and let’s find out where we are today in comparison to the nightmare. Alright, we’ve landed here in 2020 and we have our one service provider and that’s Cloudways for the interface. However, we are able to create multiple servers across multiple cloud providers. We now have a global reach as a development house and we work with clients as far away as Australia, America, even Indonesia and beyond. It’s been an incredible journey. We work with a lot of high risk clients. This means a lot of our work has to be super secure. We’re working with data intensive web apps as well where we’re making web apps such as CRM systems, etc. So this is a lot of data, again, a lot of support and security as needed behind that. We also have to support all of these websites and we’re also responsible for multiple business continuity plans around the globe.
Ensuring that some of these mission critical products that we’ve helped clients develop are online as much as possible. And if I was trying to do that in a world that we just described back in 2012 I think I would be super stressed out. Whereas if we fast forward to now, given that we have the one interface, this has allowed us to be able to create a set of documentation and some business workflows that work across all of those different project types and all of those different clients. Our experience of 2012 made us realise that we needed scalability so we could grow the platform with our clients. We needed to be able to migrate sites quickly from one place to another. We needed easy to use staging environments. We wanted to be able to run multiple websites on one server without them all being affected.
We wanted to be able to run huge WordPress multisites for some of our bigger clients, so we were going to need big databases. We were going to need big robust servers. We also want it to be able to rock and roll with the cloud players without all of the complicated tech that came with that. So we were looking for some form of managed solution, something that would allow us to support our clients and also allow us to be supported and also most importantly allow us to ensure the business continuity of our clients with high risk clients. It’s essential that the content, that data is protected. It’s also essential that those sites stay online as much as possible so that they can continue to operate their businesses. So multiple redundancy were so important and we knew in 2012 that we did not have that and we needed to shift and we were able to shift all of that by utilising cloud ways as our central management resource.
Again, there are multiple providers, we mentioned this right at the very beginning, so take a look as well at Runcloud and other platforms that might be able to do this for you as well. For us, we hit a couple of years ago on Cloudways and started to migrate all of our clients there. So let me describe some of the lessons that we learned and how we’re able to use the Cloudways platform as an example to achieve everything that we do now in 2020 I’m not going to now unpack all of the benefits of Cloudways. What I want to do is to teach you some of the key takeaways that we had from our experience that you can then apply to your business and to your provider of choice. And the first key lesson was standardisation. It was really important for us to have one platform and a particular set of processes and procedures.
This allowed us to create one set of documentation using the same interface for multiple different outcomes. In the past we were having to create multiple documents to do the same thing. Nowadays we have a very simple standard set of procedures with just a few if thence, which reference other files where needed and the if thence would only be for if a project is an application versus being a website. So that’s nothing against the platform we’re using. That’s just a simple difference in use case. This also means that no matter which server we are using, be it Linode, be it AWS, be it DigitalOcean, etc. We’re using the same interface, we’re using the same tools and what we do is the same no matter what we’re interacting with. Our next lesson was in automation, being able to deploy websites really quickly, being able to set up stack templates so that we could get straight into development sooner rather than taking ages, getting everything set up, being able to automate all of our backups and also our tracking.
Therefore I could be notified via SMS if a backup failed and I’m not constantly having to check lots of different control panels. I am notified when I need to be through a Zapier or an API integration. So these sorts of automations where we can remove steps, automate or make things quicker were really, really essential for us. And that was something that we couldn’t really do reasonably if we were using multiple providers. Following on from automation would be scalability and not being limited by the server that we had chosen. We had set up multiple physical servers in the past, whereas now I can create something, say on the Linode and if and when I need to add resource to that I can do and if I also need to move that to a completely different cloud provider that has even more resource or something that I need, I can also do that all from within the same interface.
And that practically eradicates downtime and massively reduces our cost to continue to support our clients whilst their needs change. To follow on from that, having a disaster recovery plan or a business continuity plan for any business is really, really essential. So we needed to ensure that whatever platforms we were using that it would compliment that disaster recovery processes of our clients. So again, we’ve got the same single interface that we can use for backups, for quick restores, for new server clones, etc. So we can be as quick as possible in all of our responses. And finally documentation without our processes, our setups, our support, our config. All being documented, then it’s really hard for us to provide a really good service to our clients. We started to do this in 2012 but our documentation was crazy out of control quick. Nowadays in 2020 we just have one simple set of documents.
It all lives inside of Teams. We also have a search facility set up inside of Airtable that allows us to quickly find particular articles that will help us support our clients. But it’s one set of documents for the specific productized services that we offer. And again, we’re using the same platform every single time. So for us, we’ve standardised, we’ve automated, we’ve ensured that we’re scalable, we’ve ensured that we can respond to the business continuity needs of our clients and we’ve also ensured that we have some really good, reliable documentation that allowed me last week, in fact, for the last few weeks to spend practically no time on the business whilst I got the live event ready and my team continued to support and work with all of our clients. So let’s wrap up with the good old recap. We started off in our time machine and we established where we were as a business with disparate systems supporting our clients in 2012 with lots of documentation, access details coming out of RAs and no real sense of ownership.
It was just a hot mess. We then jumped back into that time machine and we looked at 2020 where we, so we now we’re in a business that has a global reach that works with high risk clients that operates really data intensive and power hungry web apps where we’re offering website support around the globe and that we’re supporting people’s business continuity planning. We shared what we realised we needed, which was in 2012 we didn’t have the scalability, we didn’t have easy migration staging setups. We were trying to cram multiple websites onto one server and it wouldn’t cope. So we needed stuff that could cope. We needed access to those cloud players in a way that we could manage without the intense technical background that you might have needed at the time. And again, we needed to support our client’s business continuity. So our solution was to manage multiple cloud providers using Cloudways.
Again, we said this at the beginning, we said it in the middle, we shall say it at the end. Cloudways was our choice. What you really need to do is work out where your needs are as a business and find the interface that best works for you that allows you to create all of that centralised documentation. Finally we shared with you our takeaways, which was to standardise. That’s the interfaces, the tools, the processes. It was to automate those stacks. The deployment tracking backups. It was to ensure that we could scale easily with our clients. It was also to ensure that we could compliment their disaster recovery processes, their business continuity and finally it was to ensure that we had good documentation. That’s good internal documentation of our own processes, procedures, etc, but also decent documentation from the provider. Now you’ll be aware that I am a Cloudways Maverick, so my heart is for cloud ways and if you would like to check it out then can I encourage you take a look at the show notes.
They will be a link to Cloudways for you to check out and let me know what your thoughts, what are they doing well and maybe what aren’t they doing so well? What would you benefit from more? I partner with Cloudways on with this podcast, they support us so that we can bring you all of this content, but equally I support them with feedback from yourself, so it would be great to get a conversation open to find out how far Cloudways can improve their own performance. I’m also aware that people like Paul Lacey are really big on run cloud, so be sure to check out them and other service providers and see what are they doing right that perhaps other people could benefit from. I think this would be a great conversation for us to have over in the Agency Trailblazer Facebook group. You can find that over on www.trailblazer.fm/group if we don’t see you in the group, then Hey, we’re going to see you in next week’s episode.