SERVERLESS ARCHITECTURE

HOW IT WORKS:

In a serverless system, the client side browser talks directly to the authentication service associated with the BAAS. Once access is granted, another BAAS function allows the browser access to a products database fully hosted by the third party. We essentially have a single page application the third party keeps track of the client’s session, reading of the database, and translating into a usable view by offering a specific service package.

Instead of having third party servers that are always running, we can use FAAS to generate an application programming interface gateway. The user can now choose between other functions they have created themselves for argument’s sake, let’s call one search, and one purchase.

The search function links to the same product database as the BAAS, with the results populating in the browser. The search code has been ported in the original Java and JavaScript without a complete rewrite but the process is much faster, and variable function can be added at the developer’s discretion.

A selection is made in the “shopping cart” style function of the browser, before another FAAS function links to the offside purchase database. From there payment is authenticated via another third party vendor like PayPal and success the browser informs the user of their purchase.

The FAAS system has broken up different logic processes into separately deployed commands that are more flexible and easier to modify or change. Each click generates a new compute container, managing the microservices in a more efficient manner. BAAS functions like security, user authentication, and database optimization are left to run as background processes.

THE PROS:

As we’ve touched upon, cost-wise serverless has the lowest operational costs by far not too dissimilar to a PAAS situation. Paying for server management is drastically less than building and managing your own, especially if the fee structure is event based. This is great for inconsistent traffic.

Horizontal scaling and the addition of more microservices is completely automatic, developer adjusted, and ultimately managed by the third party. Sufficient resources are generated as the need arises, and as the application grows, there is no danger of overloading like there is with a traditional proprietary back end arrangement.

Time to market and development cycles are slashed, thanks to the shared computing power of the substantial third party databases and servers. Development can even be done as a continuously improved rollout, improving as you go while still maintaining operation and function no server shutdowns.

Server rooms use an enormous amount of electricity just to keep running. It’s a commendably green option to opt for serverless cloud-based operation as resources are pooled in a group, and energy is used as it’s needed with no wastage of a system running idle.

THE CONS:

After gushing about how great serverless is, it’s time to see the other side of the coin flip. It’s not all rainbows and sunshine, and there are some drawbacks associated with going full offsite third party management.

By giving control over to the vendor, you’re at their mercy. This means downtime and resource limitations are dictated by their maintenance routine. Similarly, cost changes must be accepted as each vendor will have specific BAAS tools your browser has been built to work with.

As with everything in life, trust has to be earned. Every database has inherent weaknesses that make it prone to cyber attacks and breaches, and by using a third party you are going on blind faith that their security protocols are?up?to?scratch.