I’m naturally sceptical of the promises of new technologies. When the container technology was on the rise, for example, it took me a couple of years before I would fully embrace the technology. I rarely jumped into the bandwagon of innovators or early adopters. There’s a little part of me that favours stability. I felt many times that new technologies are just moving one problem from one place to another. Besides, why would I need new technology if what I know now is working?

When I first looked into the serverless architecture, I got a similar sheer of scepticism. Is serverless that kind of technology that will just move problems around and introduce new complexities? Given a tight deadline we were given by our client, we have decided to give serverless architecture a try. I have never looked back ever since as the benefit of the technology is real. Yes, there are problems that are moved around, but from the totality perspective, the technology brings an overall positive impact. My experience is analogous to the experience of other early adopters of serverless.

Working for a consultancy though brings me a wider perspective of what’s going on in the industry, which includes the sceptics of serverless. Hearing the stories from my colleagues make me feel like serverless is falling into the chasm. I’ve heard many stories of less successful serverless adoption and implementation. Organisations are stuck using serverless technologies only in the least risky part of their architecture.

What are the ingredients that we’re missing? How do we leverage what serverless technologies have to offer better? There is a paradigm shift in serverless. When there is a paradigm shift, we need to change the way we think about this new paradigm, so that technology can benefit more people in the industry, regardless of the organisation size. A set of principles will help you take the journey of this paradigm shift, and how you should approach the adoption of serverless.

Read More

I’ve heard more people who suggest that it’s becoming a lot easier to become a technologist now. This is because the knowledge required to become a technologist, whether that’s a software engineer or system administrator, was not very accessible in the past, but this is changing rapidly. Even though software conferences are expensive to attend, many of them are made free to be watched online now. Online video courses are becoming easier and cheaper to access. As more and more technologists are coming to the software industry, many are also publishing what they have learnt as blogs online, for free.

Would that mean that everyone can be a technologist now? I’m quite sure that knowledge is not the only thing that we need to become a technologist. Talking to many technologists, I often discover that many can recite what a conference speaker had talked about. More often than not, we wouldn’t know how to make use of that knowledge in practice. If we can’t make use of them, what is the use of knowledge that we have acquired?

Read More

Whenever new technologies emerge, the first priority for a technologist is to understand the implication of adopting it. Serverless architecture is a case in point.

This article has been featured in:

• InfoQ - Characteristics of Serverless Architecture
• ZDNet - Serverless architect emerges as in-demand job role
• Hacker News

Unfortunately, much of the current literature around serverless architecture focuses solely on its benefits. Many of the articles — and examples used — are driven by cloud providers — so, unsurprisingly talk up the positives. This write-up attempts to give a better understanding of the traits of serverless architecture.

I’ve deliberately chosen the word trait, and not characteristic, because these are the elements of the serverless architecture that you can’t change. Characteristics are malleable, traits are inherent. Traits are also neutral, hence it isn’t positive nor negative. In some cases, the type of trait I’ll describe may have positive connotations, but I’ll be keeping a neutral head on this one so that you understand what you’ll be facing.

Read More

Serverless architecture has fast become a hot topic in tech, thanks partly to its promise of drastically reducing your time-to-market. Nonetheless, many IT leaders remain cautious about serverless because of their fears over vendor lock-in. In this article, I’ll explore the realities of what lock-in means in the context of serverless — and propose strategies to minimize your risks.

There are already a number of views on what constitutes serverless. For the purposes of this piece, I’m using it as described here: application designs that incorporate third-party “Backend as a Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a “Functions as a Service” (FaaS) platform. When thought of in these terms, you can see why lock-in can be a major concern. While serverless architectures might reduce your operational cost, complexity, and engineering lead time, it makes you more reliant on your BaaS provider.

Read More

In my recent client engagement, I foresaw that serverless architecture was a perfect fit. The idea of adopting serverless architecture, though, didn’t fly to our client well due to the fear of vendor lock-in. It was an interesting time for retailers as staying in AWS might mean that Amazon, as another retail business, will be given a competitive advantage. Given the idea of not supporting a competitor, my client was interested to ensure that the solution chosen by us is fully portable to other cloud vendors.

Read More

Dependency Injection is an important design pattern in any software development paradigm, including in the Serverless world. In AWS Lambda world, I was not satisfied with any of the approach that I have found. I have covered this topic previously and come up with a simple convention. That convention works, but I really want to see if I can make it even better. Introducing Laconia.

Read More