A couple of months ago I wrote a blog post about offloading your Wordpress Media Library to Amazon S3 - which I found really resonated with a lot of people I shared it with. The idea of not using a single server to host all of your images and instead offloading the responsibility to another, better suited service makes a lot of sense.
It’s actually something I’ve been thinking about for a long time now (as have a lot of other people), the general idea of moving the way systems work to be powered by a number of Micro Services, rather than single Monolith systems. It’s not a very new idea - however it’s started to become more and more popular in recent times.
Just as the name suggests, micro services are small, individual services which have a limited scope of functionality and can be called upon as and when required. Whereas a traditional system will be running on a single server and that one server will be expected to do everything, a Micro Service approach will split the required processes across a few different places to make it easier to scale up or down any component part of the system.
This style of system design is used more prominently in web applications - however the more I’ve been thinking about it, the more use I can see for this type of functionality in more consumer facing websites.
Let’s look at an example which will hopefully explain this, and also illuminate Micro Services for you if you’re not sure.
Dave has a blog, he writes about doughnuts. One day he thinks he’ll try and sell some doughnuts from his site too - so he gets a plugin for his blog which allows him to open a store. It’s not the fastest system in the world - but it does for now.
He starts to get more successful with the doughnut sales, but the doughnut blog isn’t really attracting too many readers. He thinks the best thing to do would be to start publishing an app with all of his doughnut content, but he doesn’t really want to have to write it all twice and publish it in two places - so he gets another plugin to sit on top of his blog that allows an app to read his content and publish it automatically. It sort of does the job so Dave’s sort of happy.
Dave’s now really starting to make some waves with the doughnut sales so he wants to try and sell on Amazon too - ideally he’d like to automate all of this so he doesn’t have to keep on manually listing products. Again, there’s a plugin he can get for his site but it doesn’t really work exactly as it should. He gets by though because it’s sort of working.
All the while - the blog has attracted loads of users now and he’s really doing well off the back of it. He’s got people getting in touch all day long asking him for partnerships, recipes and other connection requests all through a form on his website.
It’s just not the best thing to do. Dave’s got that one poor server in the middle which is doing so much work:
Rendering views on the front end for people to read content
Processing Sales and Inventory Information
Generating API’s for Amazon and his app
Sending contact forms every five minutes
Powering a Backend for him to manage sales and dispatch
All of this means he’s continually having to up and up the size and power of the server to cope with peak performance. He doesn’t really get anyone on the site between Midnight and Midday - so that’s a whole 12 hours his massive server will just be sat there doing very very little.
There’s ways around this of course, things like caching and load balancers could help ease the load - but it’s still something which will require ongoing maintenance and it’s one system stacked on top of another, on top of another. Wouldn’t it make more sense for Dave to split each of these things out into their own component service?
Dave starts a blog about Doughnuts, he uses a Headless CMS to write blog posts and manage all of the content within his app. He builds the website to display this CMS content using a static site generator and hosts it on a static web host.
Then when he decides to start selling products he uses an API based e-commerce platform with its own dashboard which allows him to manage orders, inventory and shipping options. He can quite simply integrate this into his website and then straight away feed the product data into Amazon.
He gets the app off the ground by using the same headless CMS API feed that powers his website, no need for additional plugins or overworking his server based on requests coming from the app.
All the while his forms are being managed by a cloud function which connects to a mail sending platform to process and deliver all of his enquiries.
I know what you’re thinking - it sounds like there’s a lot going on here - and there is. The micro serviced approach has split one server doing a lot into a number of individual services all doing something - so what’s the real advantage
Dave’s server doesn’t exist, he doesn’t have to worry about keeping on top of hacks, malware or the whole thing coming down because it was never intended to do all of this.
All of these component parts are doing their own single thing - and doing it really, really well.
All of these services are only ever being called at the time they are required - no keeping a massive instance running (at great expense) during hours when it’s not being used.
Ease of interchange - say for example a new mail system becomes available that would work out far cheaper for Dave’s needs. He can relatively quickly and easily drop his current provider and pick up a new one - without needing to rearchitect the entire system.
It all depends on how much work you want to put in upfront compared to in the long term. If you want to run some tests and see how things pan out then no - this solution is more designed for when you’re planning for the future. I’ve just setup a new web store for a sideline business I’m trying out, to get that going I just setup a Shopify store, chucked some products in there and started adding pages. If things start to pick up with the store then sure, I’ll look to move it over to a Micro Serviced system that will grow effortlessly. If it just keeps ticking over and getting a couple of sales a week - then there’s no point in setting up a system as complex as this.
Likewise, if you’re just setting up a personal blog - getting a Wordpress site or a Medium page setup would be the better way to go in the interest of speed of setup and reducing complexity.
Probably the best part of Microservices is that they are just that - micro services. You can use as many or as few of them as you like and migrate across to them as you wish (in most cases). Going back to my S3 Media Library example from the start of this - Wordpress is a traditional Monolith system, but offloading the entire media library to an S3 micro service has broken it down and taken the load off the server - and that could be the right way for you to go in the immediate short term.
My daughter’s been watching Frozen a lot recently - if you’ve also seen it, the thought of building a Snowman will bring shivers to your spine. However, if you want to have a chat about building some cool Micro service based goodness - I’m always up for a chat. Drop me an email to [email protected] and we can see if there’s anything we can crack on with together.
I couldn’t vouch for anything other than what I’ve used so far, but here’s a list of some of the big names out there, with the ones I’ve used at the top:
Static Site Builders
Static Site Hosting
API Powered e-commerce
Serverless Function Providers
Google Cloud Functions
AWS Lambda Functions