To be completely honest, the last (almost) year has been tough. We had a working version of 31Events – that accomplished the goal of sending a very well formatted iCal/ICS file, that could be “consumed” by all the major email & calendar clients on the market.
So we had a decision to make – Either make the existing platform work or to completely re-invent/code to work within an ecosystem we knew would both (1) scale and (2) be around for a very long time.
So we decided to burn it down, and start over.
What we’ve learned in the process of moving from a Coldfusion/MSSQL environment, is that AWS Serverless Architecture gives us both flexibility with the ability to scale – without us having to manage any servers, storage, or infrastructure. It’s been an interesting 9 months of learning for us — first, it’s a complete mindshift from our backgrounds (both Greg and I have spent our professional lives within “infrastructure” and services for large companies) in that we didn’t need to worry about the “backend”, that it would just work – regardless of what we wanted to do.
Second, it forced us to really think through what 31Events does – and start breaking it down into smaller and smaller pieces, because serverless architecture is about “micro” services and functions – no longer did we need to think from an end-to-end standpoint and create functions to handle it. We now shifted to smaller functions.
Third, it forced us to re-think the front-end (user interface), and what we wanted to accomplish – first as we roll out Version 1, but also what we could do as we proceeded down the enhancement and development path.
I like to talk in analogies, it helps me put things into some sort of context and understand complex “things”. To wrap my mind around the direction we had planned to take, I started thinking of our new AWS Serverless backend as setting up a dominos. Our dominos can start off as a simple line … knock over the first one, and it just knocks over the next. But as we learn and grown, we can add complex patterns, or create side tracks that go simultaneously. And each “domino” is a fraction of the whole, and if it breaks, we can go back to the specific place and fix it. It really is a great way to create an application (which is what 31Events is) and have it work right from the beginning.
Right now, we are still working through creating our micro services, and we’ve made some significant progress in doing that. Although the concepts are “easy” to understand, the implimentation is always going to much harder than originally thought.
The other problem faced, as you march down this brave new world of serverless, is finding people who really (and I mean really) understand it – and can make it work. We’ve been through a few people along the way, but hopefully have found the right team to help us going forward.
We all have “day” jobs at the moment – so 31Events is a sideline project. That doesn’t mean it’s not important (because it is, Greg and I both see examples every day where we could help people), what it means is that we can’t necessarily publish a roadmap with dates. Our first priority is to ensure we have the same functionality we had a year ago. After that, we will re-launch. Because we know, once it works, it will just work regardless of how many users we have creating and managing events & invitations.
We hope to be back with Version 1 by July – that would market a one-year absence of 31Events – but I’m not putting a timeline on it. So, stay ready, because once we re-launch, it will just work – and you will then be able to send a calendar invitation to anyone, and will just work.
Because we are here to change the world of “Add to Calendar”.