Building a Serverless Content Repository
I am starting a new personal pet project: A Serverless Content Repository. It won’t be too ambitious though, just a few content management capabilities using modern technologies. Just for fun. Building software is one of the best methods to skill you up on new technologies, and developing in the serverless ecosystem is something I am interested to learn about.
This project is open to everyone who wants to join me. Whether you want to contribute some code, or send some feedback, or just learn what I do, you will be warmly welcomed aboard. I intend to formally document the whole process here, at Medium. Although I’ll be also posting on Twitter (efoncubierta) some thoughts and progress as well.
Downside is that I don’t have much time left in the day to dedicate to this project. Work, family, cycling, reading… But I will do my best to work on it at least one hour every day. And weekends.
Why a Content Repository?
Over the last 13 years I’ve working with content management technologies, from developing small content models to architecting, and leading, projects costing millions of dollars. Started with Drupal back in 2004 and shifted to Alfresco 10 years ago, touching some Liferay and OpenCMS along the way, to be more specific.
Content is everywhere. YouTube, Instagram, Amazon, banks, publishers, TVs… they all have content repositories to manage videos, fotos, documents, e-books, etc. In fact, for most of these companies content is king. The contents they produce are the most important assets they have and, by extension, their content repositories are the most critical systems they own.
Although this project is not to create an alternative to existing content management systems — I don’t have the time and resources to do that — , it will provide a small set of features that will fulfil projects with little content management requirements. The idea is to build a simple content repository that can be safely used in production. That’s my success criteria.
Serverless is a game changer, isn’t it? Ok, maybe I am just exaggerating a little bit. Besides being one of the buzzwords in 2017, serverless is an interesting way of architecting software. I’ve been reading quite a lot of serverless literature lately, but haven’t put it in practice yet.
A content repository implemented with AWS Lambda, or Azure Functions, backed by AWS S3, or Azure Storage, and AWS DynamoDB, or Azure Cosmos DB, makes sense — Yes, Google or any other cloud provider would work too. These are serverless services, widely used by many companies. The content repository would be just a layer on top of these services.
Serverless model has similarities with the electricity model, which makes it appealing for many companies:
- Pay-as-you-go: The more you consume it, the more you will pay for it.
- Unlimited scalability: Don’t need to worry about running out of capacity.
- Delegated responsibility: Providers will take care of maintaining the service.
- Free choice: Pick the provider offering better prices, conditions and regulations for your company.
Content repositories fits well in this model.
As commented above, over the next weeks I will be documenting the process, and progress, at Medium, and disclosing some thoughts at Twitter. The source code will be available in my Github account too.
What can you do to help me right now?
- Follow me on Medium: ezequiel
- Follow me on Twitter: efoncubierta
- Email me your thoughts to email@example.com
- Clap this story.
- Comment on this story.
- Share this story on your social networks.