All that hard work all those teams did over the last 5 years, kiss that code goodbye because chances are you have overloaded your technical debt account. “But we didn’t think in terms of non-blocking, asyncronous scalable code when we started this project 5 years ago.” I used to say it all the time. Faced with the daunting task of updating legacy enterprise applications doesn’t come without huge consequence and cost.
Mobile first vs Cloud first
Mobile first design, the buzzword for this decade. Spot on, but if the engine underneath wasn’t designed in the same matter, your Mobile First Design is worthless. If your supporting services can’t handle the load of Mobile device growth explosion then what good is a Mobile First Design. Well it looks good in a powerpoint I suppose.
Can your application go from serving 1 customer to serving 1000 without manual intervention(that is even if you could do something to handle it manually)? How about scaling back down resources to only support 1 customer?
Case Study (Acme Inc)
Acme Inc sells shirts, they have an online store which they built in house. They have a mobile app that they also created, but since they aren’t cloud engineers, they only fulfilled the Mobile First Design portion of the solution. They used staff developers who had lots of experience writing highly coupled enterprise applications that follow the business needs of the company. This year a celebrity was seen wearing one of these shirts on the television. The next day Acme Inc’s well designed ecommerce system crashes on load. Everyone is freaking because no sales are coming through. The site got an unexpected swarm of new visitors due to the press. Acme had the potential to sell a lot of shirts that day, but instead they had a broken system.
Solution: Had Acme designed their systems with a Cloud First mentality, the system and its applications would have been able to grow and shrink in capacity to fit business needs and operational readiness goals.
How does your system react to adverse situations? Is it self-healing or does it buzz the beeper of the toolbelt wearing IT guy? If your system can’t take care of itself, who will? I’d personally rather have a server who isn’t drunk deciding for itself how to handle the situation.
How will your systems handle geographical spikes in traffic? Are you using a distributed CDN to deliver content? A wise business partner once said “Server availability is meaningless in an ephemeral world, service availability is the only thing that matters.” We must stop thinking in terms of server stability and start thinking in terms of service stability.