There are too many articles, videos sharing experiences about the unending ocean of technologies, each with an opinion about how they built the best in the class software which eventually helped businesses to grow and achieve maximum customer satisfaction. In a quest to understand, what it really takes to build a quality software, I realized my initial experiments were nothing but series of failures. With each experience, I could gain insight about how things can be strengthened and how ignorance can lead to disaster. With the series of “Failed Architecture”, I will touch-base on various requirements and attempt to solve the problems. With each solution, we will also explore its trade-offs and how we can mitigate it with a better approach.
To better understand, let’s start with problem definition
Bob is a commercial artist and he loves to showcase his work to the entire world. He decides to build a simple website which will provide an introduction about him and his art. All the content will be uploaded at the time of building the site and there will be minimal updates afterward. Bob being popular around the world, expects huge traffic flowing to his site. Bob thinks Jim (our architect) is best suited for the job. Bob also says that he really not interested in administering this site, so keep it as simple as possible – no admin stuff.
Problem seems to be fairly simple and it can be broadly divided into following categories
- Static Content – Picutures, Texts, Videos
- Global Audience
- No admin interface
Since the requirement is fairly simple, we won’t spend too much time on debating about frameworks like AngularJS, React, Preact, Vue etc. We will rather stick to plain approach HTML, CSS frameworks (either Bootstrap or Bulma). We will primarily focus on the infrastructure part and put our thoughts around that. Meanwhile, Bob messages Jim on Monday morning.
Let’s catch up over breakfast on Wednesday and discuss your approach. I have also invited one of my friends (Kyle), who has strong experience in Web Development. Kyle wishes to discuss infrastructure. See you there.
Well, it’s time to sketch solution and present it to Bob and HIS FRIEND. Considering above requirements, the solution seems to be pretty straightforward.
As planned, the meeting begins on Wednesday morning amongst Jim, Bob and Kyle. Jim highlights solution
- Technologies used for development – HTML5, CSS3 (with bootstrap).
- Webserver to serve and hold static content.
- Firewall to keep unwanted users outside.
Kyle seems not much impressed with the proposed solution and begins with set of questions
- What if the web server goes down? A single web server may not be able to sustain under stress situation. Too many users will eventually lead to Denial of Service and that’s definitely not good.
- What if the storage media on web server corrupts? Are we going to lose all the content? Are there any redundancies and backup plans?
- People will be accessing the site from across the globe, where the web server will be hosted? We don’t want people waiting for too long to access this site.
Bob nods and says “Jim, I believe you must have thought about this. Can you answer above question?”. Jim says sure, “Let’s meet again on Saturday and I will come up with a better sketch.”
Jim thinks about the questions raised by Kyle. He realizes that his solution must cater to following requirements. Things ain’t that simple.
- Heavy Load
- Distributed users
Jim texts back to Bob and says he is ready with his solution. The meeting begins and Jim starts presenting his solution to Kyle and Bob.
Jim is very confident about his solution and he highlights following points in his presentation.
- Storage has been separated from Webservers and there will be multiple copies stored across multiple locations. In case of storage media corruption, there is still 0% data loss.
- Frequent backups will ensure, data can be easily recovered in case of major disaster.
- Webserver can cache contents.
- There is no single web server but a pool of servers and load will be distributed by Load balancers.
- CDN will ensure fast download of static resources from immediately accessible locations.
Kyle raises his eyebrows and says “You answered all questions of the previous session, but your new approach seems too much to manage. First it’s too costly to manage such infrastructure, second, we may not have a constant load on the site, there will be spikes occasionally”. Jim knows what to do next, he says “No need to worry, we definitely don’t have to own any of these infrastructures. All of these can be leveraged on pay as you go model. Refer to my next solution – Cloud. It also has provision to autoscale web server instances depending on the load.”
Jim further explains about his approach to Kyle and Bob, “The Route53 service has a feature to route users based on location, latency. This will enable to serve content faster plus we can make use of Autoscaled EC2 instances as web servers. With S3 and Amazon Glacier storage, you need not have to worry about losing data. All the content will be backed up securely and the redundancy will ensure no data loss. The main benefit of choosing cloud is the ability to scale dynamically and pay as you go model”. The highlights of this solution are
- Highly Scalable
- Data redundancy
- High Availability
- Low Latency
- Cost Effective
- Low management overhead
Kyle seems to be interested in the solution and says “Is there any further scope of optimizing this architecture? After all, we are just building a static website, I believe there must be better approach”. Jim was already prepared for this question and he said “You are right, we really don’t have to start with such a complex infrastructure. S3 has another option of static website hosting. But be aware of this approach, you can only serve static content. You cannot do any processing of user requests, no dynamic script execution.” Both Bob and Kyle are happy with Solution suggested and closed the deal.
Did you notice, how the architecture has evolved with every iteration? The solution proposed at earlier stages failed to meet the customer requirements. Definitely, Jim has done a lot of homework. It is necessary to understand trade-offs of every approach. Jim could save another client from suffering the impact of Failed Architecture.