LCNC vs ServiceNow vs Container vs Serverless

Which platform to choose while modernizing your application?

Introduction:

I have seen many times the question comes during discussions that “which platform should we select for an application to build or modernize? Container or Serverless or LCNC (Low Code No Code) or ServiceNow etc.” And this question comes mostly when we either try to build a new application or when we try to modernize an existing application. This sometime known as Re-platform vs Re-Purchase during cloud journey.

From my experience of each of these platforms, in this article I will try to represent my view and what runs in my mind when I face that question.

While going through each option, I will explain in two modes, when to consider and when Not to consider.

Note:

* There are many products/platforms/COTS (Commercial off-the-shelf), such as OutSystems, Mendix, PowerApp, etc. But in this article I will refer mostly to PowerApps which more or less represent other LCNC platforms.

* Here, in this article I am not considering Pega as LCNC, why? That is a separate topic for discussion and arguments.

* Also I am not considering Salesforce, SAP, Workday or any other SaaS Vendor, COTS here as options, because in my experience Salesforce or any other SaaS platform has its own established defined domain of usage, and generally rarely comes in confusing discussion while choosing platform for an application.

* Nowadays, ServiceNow is also treated as LowCode platform, still I am showing it separately as an option, as it competes with other LCNC platforms during such discussions.

Key Principles and Drivers

There are no straight or defined rules to determine, but generally we analyze and consider below factors to determine which platform best fit for an application to be newly built or an existing application to be modernized.

Internal or External Users: Whether your application users are all from within your organization or there will be users from external to your organization.

Anonymous users: Will there be users who will access/use your application or some parts/web pages/modules of your application anonymously (without authenticating themselves).

DB Migration complexity: If the application already exists and you want to modernize, then assess the existing DB migration complexity and the complexity of data structure. If you are not planning to migrate the existing DB, then you need to check portability of your existing DB with the new target platform which will host the application. For new app to build, this may no be a major factor.

Vendor/COTS app : Check whether some vendor SaaS platform or COTS are available in the market to fulfill the business use cases of the application you are planning to build or modernize, and of course without any major customization.

Custom App or Customization: Validate whether you definitely need pure custom home grown app because your application needs so. Maybe you don’t have to build a custom app from scratch, but check whether you need major customization for a targeted/chosen platform to fulfill your specific business use case.

New build or existing app: Are you planning to built a new application from scratch or modernizing an existing application (re-platform/re-host/re-purchase). When you are building a new app, you may have luxary to evaluate many option, for existing application modernization that is not the case.

Security and data privacy categorization: Check your application’s security requirement and data privacy category, whether it will allow it to move to public cloud or in SaaS platform, or you need to keep the app in your operational radius.

Initial development time : Check how much static inertia you can absorb for initial development time require for initial platform setup, building the application and to host it. This can be treated as your CAPEX.

Long term recurring licensing cost: While you are checking your initial effort and cost for initial development and hosting setup, it is also very important to calculate your long term running cost of the application, e.g. recurring licensing cost, platform hosting monthly charge, etc. This can be treated as your OPEX.

Operational overhead: What is your appetite for operation overhead like patching, maintenance, backup, monitoring, scaling etc. Are you ok to sacrifice some control, security and customization to bring operational efficiency? This can be treated as your OPEX.

Citizen Developer: Is your organization promoting the Citizen Developer model to reduce developer involvement? This can be treated as your OPEX reduction. In this model, business users are Citizen Developers who can design a lot of screens easily, define workflows independently with limited training.

Integration type and number: What kind of integration your application will use with other peripheral systems. e.g. REST, SOAP, IMAP, SFTP, SMTP, gRPC, UDP, WebSocket. And how many integrations we are considering with other systems. Does the application need auto retry, failover, requeuing mechanism on integration failure? Some of the protocol and integration patterns could be roadblock for specific target platforms.

Current team’s capability: Does your current team have expertise/experience in any special language, platform? Do they have any affinity to any specific tech stack while being stakeholders of the current applications.

Responsive UI: Whether the UI of the application has to be responsive so that it works seamlessly with all resolutions of the UI available on different types of devices.

Offline mobility: Is the application mainly a mobile app, does it also need offline support?

State persistence: Please verify whether your application is stateless or stateful. Some platforms may not support the state persistence.

Nature of business use case : What is the overall purpose of the application? What kind of application is it ? e.g. MDM (master data management), Analytics, Messaging, reporting, analytics, big data, simple workflow, ETL, complex BPM, CRM, ticketing, data streaming, etc. Accordingly select the right SaaS, COTS, Vendor app or build custom app and deploy in the proper platform.

Control over DevSecOps: Does your organization have a defined DevSecOps platform or pattern which you must follow? For example, Jenkins or Azure Devops is the platform of choice in your organization’s DevOps pipeline, or all applications have to be scanned via a specific security scanning tool (e.g. aqua, sysdig, snyk, etc.) before it get deployed to production. Also check whether you have any specific code repository related branching, reviewing, scanning practice or requirements supported by specific platforms or not. Roll back strategy is also another major concern while deciding the target platform.

Control over scalability & capacity planning: Do you have a requirement to custom control over scalability and capacity planning, for example, on weekends only one server ( schedule scaling) needed, on weekdays scale based on load of CPU ( auto scaling), for batch load spot instance needed, During Diwali 50 servers always. And check such custom scaling and capacity planning supported by the platforms of choices.

Infrastructure Agnostic: Your or your organization goal is NO vendor lock-in strategy, then chosen platform need to support that.

Architecture Pattern: Do you have any specific requirements of any specific architectural pattern, e.g. micro service, pub-sub (async), batch, real time-stream. And check whether those must have architecture patterns requirements supported by the platforms in your wish list.

Deployment architecture: (availability, reliability, scalability). Does your application have any specific deployment architecture requirement? for example any need of geo-location/ geo-proximity load balancing, specific backup strategy, failover requirement, allowed deployment downtime, deployment model (blue/green, canary, rolling, etc.). Accordingly match the supportability of those requirements against different platforms.

Long term strategy: Stay informed and aligned with your organization’s long term strategies. Maybe your organization has a strategic partnership with a specific platform, or has a license discount for a specific vendor, or your organization’s strategic goal is to increase operational efficiency.

Container Platfrom :

There are many container platforms, for example Docker on VM, VMware Tanzu, K8s over OpenShift, AWS ECS Farget, AWS EKS, Azure AKS, Google GKE and many more. We will not go into discussion of comparing different container platforms. In general we will see when to consider your application to be containerized and running on any container platform.

Though there are many container platforms, I prefer and suggest serverless container platform (e.g. AWS ECS-Farget, EKS-Farget etc.)

When to consider :

If any one or many of below criteria are fulfilled then you may consider your application to be hosted in container platforms.

• If the application has to be a Custom app and can be containerized.
• You need Multi Cloud Platform portability, for no vendor lock-in.
• You already have a team experienced in a specific programming language and you don’t want to lose time to train them in a new platform, as they already know existing applications.
• Vendor apps provide their container image and you want to run in your private cloud or in your managed public cloud instance.
• If the application has a lot of integrations. or any specific integration protocol which is not supported by other SaaS/COTS platforms.
• The application has some network dependency with your own data center, which is a roadblock for using other SaaS/COTS platforms.
• When Security, data privacy is the concern, and you want to manage those yourselves.
• Need more control over DevSecOps.
• Planning for Extensibility and more choice of design patterns.
• You want to avoid recurring licensing costs (for the application). Less OPEX.
• Your application has to support internal and/or external users.
• Application needs high demand of scalability with more control, Options to decouple services so independent scalability of different services is possible. All platforms options provide scalability and auto managed, but for container platform scalability in your control.
• Taking advantage of other cloud vendor specific services (AWS S3, SES, SQS, etc.), and easy integration with those in your application.
• Need more control over Data and Data Structure.
• During app modernization, it is an easier migration path compared to Serverless.

When NOT to consider :

If any one or many of below criteria fulfilled then its better NOT to consider your application to be hosted in Container platform

• The application is a Data platform or reporting platform
• This is a new application and you have very little time before 1st go-live.
• Functionality of the application’s use case is readily available with SaaS/COTS vendors with no or little customization.
• You are NOT ok to spend effort creating UI or modernizing UI to be responsive. You don’t have time & effort for creating UI or modernizing UI to be responsive (content that adjusts smoothly to various screen sizes based on different devices.).
• If the Vendor app does NOT provide a container image to be run by you.
• Your application has strong accessibility requirements and you need to spend a lot of effort in building that, in that case some SaaS/COTS platform provides that as in build solution/features.

Serverless (FaaS — Function As A Service)

When to consider :

If any one or more of below criteria are fulfilled then you may consider your application to be hosted in Serverless platform.

• If you are planning for a short running work load, low compute consuming application components/modules.
• Goes well with event driven architecture or Micro services.
• If you are building an api driven stateless application.
• Less operational overhead is your major consideration.
• You application has non predictable ad hoc load, and yet not too much invocations ( e.g. not more than 80K api call per month)
• You are liking the model pay/bill per invocation/execution, pay only for the time your functions are running. Zero cost for idle time.

When NOT to consider :

If any one or more of below criteria are fulfilled then its better NOT to consider your application to be hosted in Serverless platform.

• If any preferred language of coding which is not supported by the desired serverless platform.
• Application/module with long running work load, high compute consuming application component/modules. Resource heavy processing.
• You need stateful application,
• You fear vendor lock-in.
• During app modernization, moving to serverless is a complex and tough migration path compared to Container.
• Sometimes running costs may be higher if load usage patterns are not analyzed and monitored properly.
• Complex apps can be hard to build over serverless.
• Serverless pattern/platform not for front-end modules to build.

Service Now:

When to consider :

If any one or more of below criteria are fulfilled then you may consider your application to be hosted in ServiceNow platform.

• Application is for Generic Ticketing system, service desk/ticketing/workflow, Incident management, service request rising, follow up, resolution. OR the application has something related to IT service management.
• Your application has to support only internal users. If the users of the application are your own organization. internal user facing, not for External users (outside of your organization)
• Less operation overhead (Savings from patching, stay current). Ease of deployment, administration, and maintenance.
• Your application tagged with less security concern.
• Just be careful not to customize too much.
• The licenses are expensive and recurring .
• If your future envisioned scope/requirement/architecture can be fulfilled within this ServiceNow platform only.

When NOT to consider :

If any one or many of below criteria are fulfilled then its better NOT to consider your application to be hosted in ServiceNow platform.

• Your application has to support External users.
• Does not involve any incident or service request or ticketing or tracking requirements or similar kind of resolution workflow.
• Requirement of complex architecture or design patterns which are not supported.
• Lots of customization needed.
• For existing applications DB layer migration is challenging
• Complex architecture, aggressive performance tuning required.
• There will be users who will access/use your application or some parts/web pages/modules of your application anonymously (without authenticating themselves)

LCNC (e.g. PowerApps) :

Though below points are for LCNC, but mainly keeping PowerApps in mind.

When to consider :

If any one or many of below criteria are fulfilled then you may consider your application to be hosted in the LCNC platform.

• Application having basic/standard business processes, involve some workflow. Application has a well defined business process.
• Build Faster is your aim. Low development time accelerates application development.
• Business User is Citizen Developer. A business person can design a lot of screens easily, Define workflows, with limited training.
• Your application has to support only internal users. If the users of the application are your own organization. Applications having internal users facing, not for External users (outside of your organization).
• Application has less security concern.
• Application needs less and easy Integrations. Simple integration preferably over REST/SOAP ( 80/443).
• Creating Responsive UI is not a headache.
• Just be careful not to customize too much.
• The licenses are expensive and recurring.
• Your future envisioned scope/requirement/architecture can be fulfilled within this LCNC platform only.

When NOT to consider :

If any one or many of below criteria are fulfilled then its better NOT to consider your application to be hosted in the LCNC platform.

• Your application has to support External users.
• Does not have any workflow requirement or defined process.
• Application is for Master Data management.
• Lots of complex and low latency integration requirements.
• Requirement of complex architecture or design patterns which are not supported.
• Lots of customization needed.
• For existing applications DB layer migration is challenging.
• Complex architecture, aggressive performance tuning. Debugging, performance tuning can be difficult at times (sometimes).
• There will be users who will access/use your application or some parts/web pages/modules of your application anonymously (without authenticating themselves)

At the End :

After you have completed your fitment analysis for functional use cases, technicality, effort and other different factors mentioned above, don’t forget to consider below factors, which can override your decision at the end. These are mostly your current capabilities and organization’s strategic direction as a whole.

• Current platform ecosystem. If you’re most of the applications are in platform X, then better to give preference to platform X.
• Availability of trained resource on different skills.
• Current team’s existing experience.
• Capex vs Opex priorities.
• Organization’s strategic goal/direction.

At the end you also need to remember that it is not always you have to choose only one platform to run your application, you may take best of all options to host your application module in multiple platforms. For example, for a single application, the simple workflow is defined in the ServiceNow, while the complex admin module in the containerized custom app. Another example could be, for a application, some complex heavy computing modules running on containers while the light weight event driven modules/api running on Serverless.

Note: Opinions and approaches expressed in this article are solely my own and do not express the views or opinions of my employer, any software vendors, or any other organizations.

Some of the product names, logos, brands, diagrams are property of their respective owners.

Please: Post your comments to express your view where you agree or disagree, and to provide suggestions.