Introduction​

A discussion which comes up often with our clients is that of Single vs Multi Cloud Strategy. Its an interesting topic to dig into and whilst benefits are evident for both approaches, it largely depends on the perspective you are coming from.

Lets do the TL;DR - Fenergo as a SaaS Vendor align firmly with the Single Cloud approach, partnering with AWS works exceptionally well from our perspective based on the type of software we create and in this post I'll look at why that is the case and also why some IT Professionals might favour a Multi-Cloud strategy.

Introduction​

DynamoDB is the most popular NoSql database on AWS. It allows you to easily build highly performant applications, taking care of the good practices, such as: encryption, access control, high-availability, backups, etc.

DynamoDB allows you to configure two types of capacity allocation: provisioned and on-demand, and it defines the capacity with read capacity units (RCU) and write capacity units (WCU). One RCU is one strongly consistent read or two eventually consistent reads for a data block of up to 4 KB. On the other hand, one WCU represents write request for a data block of up to 1 KB.

Introduction​

SaaS Solution providers can live or die on the basis of availability. There is a massive shift of responsibility to the vendor, who must ensure that users along with their data are protected and safe (a massive and separate topic) but that the solution is available when the clients want to use it.

This is no different to browsing Netflix only to be told "Sorry were having some technical difficulties at the moment" or "There are too many people watching that Movie right now". A SaaS product from a Fintech such as Fenergo might seem a million miles from a streaming service, but there is commonality in the target outcomes.

Introduction​

As a Technical Advocate for SaaS Engineering here in Fenergo, my goal is to help our technical consumers get the best from our platform. For over 10 years our products have been helping to protect our clients in adhering to an evolving list of regulatory obligations and our latest CLM platform continues to deliver that protection but as a fully Cloud Native, API First SaaS solution.

Through our own SaaS transformation, we know what that change of strategy means for our clients and in this post I’m going to touch upon the kind of topics and subjects we have encountered as our clients also transform and adopt SaaS.

The Challenge​

How can you tell when you've shipped production code? Some like dashboards, some check release notes, others still prefer to subscribe to alerts. All three groups look to me in confusion when I say you can do it with baked goods.

Introduction​

Deploying code to production automatically, often, and quickly is a principle we follow for our Fenergo SaaS CLM Platform. It brings with it many benefits, but also demands that a certain set of standards are followed to ensure it is done successfully.

Introduction​

A huge part of implementing any process orientated platform, is designing the conditional logic which gets applied at programatic junctions. This is responsible for directing and controlling the flow of logic in an application, reacting dynamically to user or API interactions. The most effective way to implement such requirements is to employ a "Rules Engine" that can apply that conditionality in a standard, reusable way.

Business Rules as they apply to an evolving regulatory landscape, introduce a lot of diversity. In short, rules will change frequently and rapidly. Our goal was to make our implementation flexible and customizable, allowing the end-user to set rules without the need for any code modification or deployments, whilst we also wanted to ensure the performance met the SLA commitments we adhere to for clients. The rules engine in our SaaS application is designed to meet numerous functional use cases across the platform, from controlling the visibility of data fields within our UI to triggering conditional steps in our workflow engine. This means it is used frequently and cross cuts a lot of other functionality. In designing it, we knew It needed to work well.