IoT is rapidly transforming manufacturing, energy, healthcare, and several other industries. The ability to predict asset failure, rapidly diagnosis...
Building a AWS Headless CMS
Over the past several years, Metal Toad has launched several successful cloud-first web and mobile applications, often with hardware components. With each release, I'm noticing how product management, UX, and engineering are frequently able to produce the same features of a CMS faster and cheaper than using Drupal, Wordpress, Salesforce, and Adobe.
This article is one of Metal Toad's Top 10 React JS Tips. Enjoy!
Over the past several years, Metal Toad has launched several successful cloud-first web and mobile applications, often with hardware components. With each release, I'm noticing how product management, UX, and engineering are frequently able to produce the same features of a CMS (management UI, publish/unpublish/schedule, comments and notifications, social integrations, etc) in equal to or less time than they could with Drupal or Wordpress. Moreover, the three year total cost of ownership tends to be substantially lower due to cloud utilization-based payments, micro-services, and a larger of AWS managed services talent. I've also grown increasingly concerned about how to ethically advise customers with CMS implementations due to rising licensing costs, reduced open source communities, and a notable reduction in labor market interests. In the following three blog posts, Nathan Wilkerson and myself will explore an AWS CMS as a feasible alternative to Drupal, Wordpress, and other enterprise CMS solutions.
What do you mean by "AWS Headless CMS"?
By AWS Headless CMS, we mean the architecture of ReactJS, a cloud data store (Dynamo, Aurora, etc), cloud routing and controllers (API Gateway and Lambdas), and a variety of micro services for authentication, e-mail newsletters, video streaming, and other common CMS needs.
Why are you considering this?
We have a several examples of medium-sized web/mobile apps for enterprises that were faster and cheaper to build than medium sized Drupal websites. Moreover, the talent we hired enjoyed the application builds, whereas the Drupal developers wanted to either move on to other technologies or move on to other companies if they could not with us. For a salient example of that last point, the latest StackOverflow Developer Survey says this about Drupal/Wordpress/etc:
- PHP has dropped to the 5th most dreaded language - right below the 70 year old Assembly language.
- Drupal has dropped to *the lowest rank* on framework usage, and the #1 most dreaded framework on the market.
- AWS has skyrocketed to the fourth preferred development platform (think about that) behind Linux and Windows.
- Wordpress has dropped to the #2 most dreaded platform.
But wait - isn't it too much custom code?
Over the years, I've had thousands of conversations about off-the-shelf and custom-code. Where I've landed is that off-the-shelf often equates to more manual configuration than custom code. The difference is that manual configuration, while more expensive with payroll and subcontractors, has a greater shared accountability model than custom code, which only developers can access. This isn't an excuse: manual configuration for most medium-large sized digital investments is rarely cheaper, and often more expensive, when measured at the 3-5 year timescale. The killer hidden cost is payroll time.