Insights

Serverless architecture Series (Part 2: Deeper dive into serverless architecture)

I hope my previous blog gave you got a good start at learning about serverless architecture. As promised, here is some more information on this topic to enrich your understanding of this implementation pattern. That’s right, in my opinion it is an implementation pattern. Because if you dig deeper, it’s not like there aren’t going to be any servers or backend systems. There will still be functions deployed as microservices, but isolated to a level that it’s easy for it to be scaled quickly.

So what makes an application serverless?

There are essentially four features that help convert your traditional functions and services to serverless. These are:

Zero administration – One of the primary goals of the serverless-based microservices model is to provide the freedom to developers to deploy the code without provisioning anything beforehand, or managing anything afterward. No more dependency on the infrastructure/Ops teams. No concept of an instance, OS running on that instance, or any instance management overheads.

Auto-scaling – Secondly, serverless-by-design lets your service providers manage the scaling challenges. There’s no need to fire alerts or write scripts to scale up and down. This allows for handling peaks and turfs in traffic and also the occasional lulls on the weekends, without any manual intervention. Tech serenity, if you ask me!

Pay per use – The concept of Function as a service provides the ability to compute and manage services based on usage, rather than pre-provisioned capacity. No more paying for idle time. The results could be significant, in some cases up to 90% cost savings over a cloud virtual machine. That’s real business value right there.

Increased velocity – Driven by the quick-to-market needs of today’s business models, this whole concept of being serverless gives developers the proverbial ‘wings’ and enables them to deliver functions on the fly. This is great for the Agile model of proving a functional concept and then designing it further.

To summarize, the major advantages of a traditional cloud model vs serverless are:

Cheaper than traditional cloud – you only pay for the time these functions are running

Scalable – support your business spikes and lows more efficiently

Lower human resources – Once its set and configured, theoretically the system does not need human intervention. You do need to monitor the logs and take actions when the system performs out of the set limits

Focus on user experience – this is key for business. As discussed throughout this blog, the whole concept gives business the ability to be agile in a true sense, allows them to try out new things, and fail quicker and move on to business models that actually work. It’s a win-win for any business.

Is serverless the silver bullet?

Well, not exactly. As with any other new technology, it does come with its own challenges. Some of the obvious ones include:

  1. Vendor lock in – At this point, the cloud service providers do not provide cross compatibility. Why would they? It’s not in their best interest. So as a consumer, you are locked in with the platform where you start. From the developer’s perspective, this is not as bad. Though when they have to integrate with services hosted on a different platform, they may have to negotiate a lot of challenges, such as connectivity, protocols, security and so on.
  2. Learning curve – Serverless is a new concept and it does take some time for teams to ramp up to make the best out of it. Nevertheless, there are new developments happening all the time. For example, there are a Serverless Kit and a Serverless Platform being designed by some experts, which are supposed to ease all the challenges mentioned here.
    • Tip: I’ll be covering the severless kit in one of my upcoming blogs. Do keep an eye out for that!

But is it secure?

Absolutely, as long as you make it so.

As the architects would tell you, the details are in the design! As with any enterprise service, you need to design with security as a primary requirement of your application. You need to account for the fact that users will be interacting with this service directly, sometimes using their credentials. So, it is important to clearly understand how to limit what resources they have access to, what they can and cannot read and write.

It is highly likely that your service would be interfacing with 3rd party services, and it is imperative to consider the access to that service. For example, with Firebase (a real-time streaming database), you write custom security rules that are executed by the database engine to determine which users can read or write from different parts of the database. If you are writing your own micro-services, then you need to ensure that your services check the authenticity of the security token passed and verify the rights of the user.

I hope this blog helped you get a deeper understanding of serverless services. I’ll continue with our series in the next installment, covering a toolkit that helps reduce the burden of starting with this great platform. It has an obvious name of ‘Serverless Framework Toolkit.’ Until then, adios!

Interested in learning more? Contact our team today.

sales@us.beyondsoft.com

Connect with us on social media!

LinkedIn

Twitter

YouTube

Check out other blogs from Arun.

Serverless Architectures Series (Part 1: What Is SA?)  by Arun Chhatpar

なぜ私たちを選べますか

私たちのオンショア、ニアショア、オフショアのデリバリーサービスは、24時間365日、お客様のビジネスをサポートします。日本の大手SI企業に対し数十年にわたりサービスを提供しています。1999年以来、日本で25年の経験を持っています。日本には500-600人のスタッフがいます。長年にわたる成功事例は、私たちがお客様の投資対効果においてどれほど重要であるかを証明しています。シンガポールは私たちのグローバル本部であり、世界各地に14の地域オフィスを持っています。

30年以上にわたる強力なITコンサルティングサービスの経験

COBOL, C, Java, Pythonなど幅広い開発言語や開発環境に対応

SAPにおけるABAP, BTP, Fioriなど幅広く対応

40以上のグローバルデリバリーネットワークを持つ4大陸をカバー

CMMI 5、ISO 9001、ISO 14001、ISO 20000、ISO 27001、ISO 22301、ISO 45001、TMMi5の認証

マイクロソフトの専門家であるAzure MSP

Beyondsoftと共にビジネスの潜在力を最大限に引き出しましょう。私たちがどのようにイノベーションを推進し、効率を向上させ、ビジネスの成長を実現するのか、ぜひご相談ください。

jaJapanese