Lessons from the “Storming of the Capitol” incident in early Jan 2021
Manglu Balasubramanian
Most of us have seen and read about the unfortunate incident on the 6th of January 2021: “Storming of the U.S Capitol”. There are a number of lessons that we (not just the folks in the US) need to learn from this incident. The lessons learned will cover a broad spectrum including Moral, Political, and Technology.
This article focuses on the usage of Cloud technology and how one of the social network/media players — Parler got booted out and what is the lesson in Business Continuity from this incident for the other players.
Note: This article is not about whether Parler should be banned or allowed to continue and whether these decisions taken by the big players (AWS, Apple, and Google) are right or incorrect.
The modern technology world consists of a number of ecosystem components/players that can be broadly be classified as follows:
Platform Providers: Players who provide a platform on which solutions are hosted. AWS (Amazon), Google, and Azure (Microsoft) are some of the big platform players that provide the infrastructure and services that are leveraged by the innovative apps/organizations.
End-User Devices: These are the devices used by the Joes and the Janes to access various applications and services. For most practical purposes, these are mobile devices such as phones and tablets. The players that dominate this space are Apple (with their iPhone and iPad devices), Google, Samsung, and their likes (which use the Android Platform), and to a lesser extent Windows-based devices (Microsoft ecosystem).
Distribution Platforms: These represent the platforms through which the apps are distributed to end-users (and their devices). The big players here are Apple (AppStore), Google (Play Store), and Microsoft (Microsoft Store)
Application Providers: This group represents the innovative players who create the millions of applications that are enjoyed by the end-users. The breadth of apps is only limited by our creative ability as is evidenced by the hundreds/thousands of apps that are registered in the various App Stores and Play Stores (Distribution Platforms).
Before we dwell into the “Parler” storyline, let’s see how this picture above looks for one of the largest players — Google.
Google is one of the very few players who truly control their own destiny. They play a role in all the key ecosystem components. Their solutions are hosted in Google Cloud Platform (GCP). They build their own applications (e.g. GSuite apps). They distribute their applications through their own store — Google besides the Apple App Store. They even have a hand in the mobile devices (Google Pixel phones) that are used by customers. The other application providers are not in such a sweet spot as Google and are heavily dependent on others for their own future!
Let’s get to the Parler story now. They provided a social networking application that purportedly considers privacy as paramount and free speech as essential. These were likely some of their differentiating features/capabilities compared to its competitors.
Note: We are not that interested in their value proposition (providing this information just as a side note for those of us who have never heard of Parler prior to the U.S. Capitol incidents).
Who was their Platform Provider(s)?- Amazon AWS.
What were their Distribution Platforms? Apple AppStore and Google Play Store
What were their end user’s using devices? Unsure about the laundry list of devices however they are likely to be the Apple iPhones and various Android-based distributions such as Samsung, One Plus, etc.
What happened soon after the 6th January incident at the U.S Capitol?
(a) Google and then Apple banned Parler from their distribution stores.
How did this affect Parler’s Customers? New Customers could no longer install the Parler app and existing customers wouldn’t be able to upgrade their version of the apps.
Existing customers could still use the app and new customers could use their website (and possibly other distribution platforms that had not banned them) to get access to the app.
(b) AWS first suspended Parler’s account and then in a day or two terminated their account
How did this affect Parler?
The Parler service is not available to its customers. The Parler app on the Customer’s end-user devices is a “dud app” rendered useless as the services that the app is working with is no longer up and running.
Parler as the provider couldn’t post any upgrades to their applications on the Apple AppStore and Google Play stores.
The outcome is a Disaster has struck Parler and they are now not providing their services to its customers!!
What if this were an essential application and not a Social media App?
Honestly, if a social media/platform app is not available that is not the end of the world. However, replace the provider — Parler with another provider that provides say a financial app that allows people to make essential financial transactions. If the app is banned from the Distribution platforms and suspended or terminated by the Platform providers then the consumers (end-users such as you and me) will be terribly impacted.
What are these financial and other essential app providers doing to protect themselves and consumers from a similar situation?
The following table shows the typical Disaster Recovery (DR) strategies that are used by application/solution providers.
Let’s see how each of these typical (and popular) DR strategies would have worked in the Parler scenario
A: Single Region (Multi-AZ Deployment): Parler was hosted on AWS and since their account was suspended and eventually removed, the applications hosted in this topology would not be available to their consumers.
B: Multi-Region (Single Cloud): For the same reasons as (A) above, once their AWS accounts were suspended/removed, the applications were no longer accessible to its consumers.
The idiom “ Put all eggs in one basket” best sums up the two strategies above. Cloud Providers and their qualities of services (QoS) have improved over their years and it is rare for multiple regions to fail at the same time. However, in the scenario that Parler found themselves in a couple of weeks ago, they had relied on a single basket (AWS) to host all their eggs (applications).
Moving on to the other two strategies:
C: Multi-Cloud: Parler did not use this strategy to deploy their applications on multiple clouds (say AWS as their primary cloud and another cloud e.g Google Cloud as their DR cloud platform). Hypothetically, let’s assume they did and their choice was as stated above.
This would not have worked either: Why?
Google had banned Parler from their distribution store (Playstore). Their Cloud accounts would have been suspended/terminated for the same reasons.
D: Hybrid Cloud: Like C above, this is another strategy that Parler had not pursued. If the DR solution was hosted on an On-Premise data center, there are good chances of the applications being restored in their data centers and still being used by Parler’s consumers.
Challenges in these DR Strategies:
The DR strategies A and B are probably the easiest to realize. They are hosted on the same platform (in this case AWS). The underpinning infrastructure services and programming paradigms are the same. The Cloud Platform providers provide the tools to easily realize these DR topologies.
Strategies C and D are not easy to realize considering that the platforms(e.g AWS and GCP or AWS and Azure) are very different and the way the application is designed and architected plays a significant role.
If the Parler solution had used services that are available only in the AWS Platform (e.g Lambda, Kinesis, DynamoDB, etc) then moving them to a DR platform such as Azure, GCP or others isn’t a simple exercise. If and when the world of a common programming model across multiple cloud providers eventuates then maybe this task becomes easier. However, this model doesn’t exist today and may or may not eventuate in the future.
What should Application Providers such as Parler have as their DR Strategy?
The biggest lesson for application providers is to design and architect their solutions so that they can be deployed on multiple cloud platforms (not just a single platform and being locked-in to that platform). If the application providers have their own data centers, (e.g typical large players such as Banks, Energy/Telco companies ) they should leverage hybrid cloud approaches and have their On-premise Data centers as a viable DR solution.
One of the key elements of DR is Data replication. In most cloud platforms, the data egress charges aren’t trivial. Organizations should think through this aspect carefully.
There is a popular myth that if we deploy the applications as containers on a Kubernetes Platform then one can easily use the multi-cloud/hybrid cloud DR strategy. Real-life solutions/applications use a lot of components (managed services in particular) besides just containers (and container platforms). Embracing and adopting Containers is certainly a step in the right direction and bear in mind that this just one piece of a larger puzzle (i.e. not a silver bullet!).
What’s the current status of Parler?
The Parler website is now back online (approximately 10 days after it went offline). The Parler app is still not functioning (at the time of the publication of this article 28th Jan 2021— 3 weeks and counting!!…).
Finally,
Events (such as the U.S Capitol Storming and COVID-19 as we learned in 2020) are things that are outside our control. However, they have a significant impact on our applications/solutions availability and even an organization’s survival may be at stake. Application providers should carefully formulate their Business Continuity (BC) strategy, a large and complex topic, that should include scenarios such as Suspension and/or termination of services/accounts by the Platform Providers and Distribution platforms.
The policies (and guidelines) that are used to make these decisions broadly fall into two categories — One’s that are formulated by the Providers (AWS, Apple, and Google in the case of Parler) and the other being policies that are provided/dictated by the regulators (and the regulatory frameworks). A careful understanding of these policies and their implications are a must for every application provider.
I would like to end this article on a note stating that large players (even those that are Platform providers and Distribution platforms) are not immune from policy changes that affect their applications and services. A recent case in point is the New Media Bargaining Code (in Australia) that affects the social media giants Google and Facebook in particular.
Application providers (both large and small) should stay abreast of the current happenings (policies, frameworks, regulations, etc.) both in their geography and the broader wide world and be prepared to constantly refine and upgrade the BC Strategy (and Operations) to thrive in the constant ever-changing world that we live in.
Acknowledgments
I would like to thank Kyle Brown for his comments and review of this article.
References: