Microservices – Sensible Software Solutions

August 21, 2019
-

Digital Transformation -Stay Ahead Of The Curve

Category : Development , Digital Transformation , Microservices , Serverless

Digital transformation is real. If we do nothing it will result in what could be a digital stagnation. Transformation is not a final goal but a continuous process of improvement. The word digital was first used in the 15th century. It took a different meaning with the invention of computers and the first electronic digital systems in the early 1930s and 1940s. Digital transformation has been happening over the last 100 years.

So, what does the digital transformation in the 21st century really mean?

The digital transformation at this time stands for how we gather data using modern technologies to gain insight in order to better serve and engage customers, employees, and businesses. We could extend that to serve humanity as a whole.

The undeniable fact is that we produce and gather more data than we are able to comprehend and analyze without the aid of machines. Is this good or bad? It depends on the quality of the data that we collect and the benefit that we derive out of it to overall serve people better. Excessive data collection and consumption could become an issue just like the plastic waste that we produce. People are losing their lives while trying to capture the very moment of their lives in the selfie culture.

Digital transformation consists of various components. Some of them are IoT, 5G, AI, blockchain, NLP, ML, big data, analytics and cloud native applications. The rest of the article will primarily focus on the software application aspect of this transformation.

Technology Leaders

Amazon, Apple, Google, Microsoft, and Facebook are continuously inventing to solve their business problems. What we call digital transformation is something the big companies have been doing for a long time. Digital transformation is a process and not a final product. Most of us are only catching up with the pioneers in the field. If we are too late to catch up, it could become the dreaded legacy that no one is proud of. As an example, Netflix OSS dropped their own tool Hystrix for Reslience4J. Another example is that of Google which stopped selling their Google Search Appliance (GSA) product in 2016. Many organizations that invested in GSA had to quickly transform their businesses to use Elastic, Solr or other proprietary search engines.

We need to understand that these companies are not trying to build frameworks for the sake of building frameworks. They are solving the business problem that they are facing. If the solution is irrelevant they move on.

Digital Transformation Failures

Many digital transformation projects fail according to a Forbes article in 2016. The same sentiment held true in a Harvard Business Review article in 2018 and even today among business leaders.

A major university in the east coast with tens of thousands of users spent three years implementing a digital transformation solution for their students. By the time they finished their product, they were already in a legacy system that approached the end of support and needed an upgrade. The choices that they were facing were either spend another year or more upgrading the system, or build a new system. The transformation product that they choose already became a legacy and not the right solution. Three years is a lot of time in the era of digital transformation. In that timeframe, anything we build could become a legacy.

It is inevitable that all organizations need to transform. It is a challenge that many are not able to succeed in.

Fortune magazine did a special investigation report in early 2019. According to that report more than $36 billion dollars were spent over a 10 year period to digitize health records. It was a major failure. It is unfortunate that some of those errors resulted in the loss of lives.

Digital Transformation Success

There is a centuries old proverb in Tamil which says “Even when throwing (spend money) in a river, measure what you throw.” It applies greatly in the age of digital transformation. Many organizations throw their money into the river hoping that their misfortune with technology will change. It does not work that way. Intuit is one of the companies that has seen some great success with their digital transformation. A company that helps people keep their books does seem to know how to keep their books right.

There are a few things that companies can do to have a successful digital transformation.

Usability. Anything that we build needs to intuitive. It should not require 4000 mouse clicks a day for a physician to perform a shift in ER. We can’t expect our users to be developers who know how to work around the system to get their job done.
Accountability. Often teams blame others including the product they spent months choosing, or the vendor that they vetted through RFP process for the failure. We need to own the responsibility.
Measure as we spend. It is important to look at the returns whether it is short term or long term and be able to justify the cost.
Small steps. We need to learn to walk before we can learn to run. Identify some areas that can be transformed and make it a model for the company.
Assess before adopting. A lot of the technologies out there are to some extent a fad or hype. Don’t be afraid to look under the hood. If you need help, choose a trustworthy partner. Organizations often choose the wrong product or platform and then try to find a partner who could help them transform.

Stay Ahead Of The Technology Curve

It is important that we always look at the problem that we are trying to solve and understand why we are doing what we are doing.

Many organizations may not have the necessary means to invent their own transformation tool. It is perfectly fine. Everyone doesn’t have to invent their own plane in order to fly in it. The key is to understand the purpose and limitations of the tools.

REST API became very popular since the early 2000s. Along with that came the Javascript frameworks which made it easy to build applications. Teams started building apps that made dozens of request to update various sections of a single page. This soon became a major issue with all the overhead that comes with every single request. Solutions such as Websockets were proposed to reduce some of the overhead. Even though the data can travel at the speed of light, we share bandwidth just like roads and bridges.

How did some organizations solve this problem? Some organizations built view optimized tables, caches and even relied on flat schema search engines such as Elastic to reduce the number of requests. Facebook solved this problem by building their own solution and called it GraphQL.

Is GraphQL a final solution to all problems? It is definitely not. Now you have to scale the GraphQL server in a similar way you would have to scale any of your database and applications to support all the traffic. We just introduced one more layer to the problem.

What did AWS do with GraphQL? They found an opportunity to take this and make it into AWS AppSync. AppSync relieves the end users of the pain and effort of maintaining another layer. Organizations that are early adopters often may face the challenge of doing everything themselves. The companies that are at this juncture should evaluate which path to choose for a successful digital transformation. Should you spend years building you own or find one that saves you years of effort?

The same applies with Kubernetes. Within a short time of releasing Kubernetes, a whole bunch of companies popped up to tell you how Kubernetes can be made easy and painless so that you can focus on solving your business problems.

Choose wisely a platform or a cloud solution that lets you focus on the business rather than building massive technology teams. At some point an organization may find itself at the crossroads of becoming the pioneer. If it happens, let it be so. Don’t be afraid to pick up the baton. Thirty years ago, some of the major players transforming the field right now were either too young or yet to be born.

Conclusion

We are in a time where a team may be relying on tools and contributions from Microsoft, Google, Amazon, Facebook or Netflix to build a single solution. It is perfectly fine to work with multiple technologies. We are solving business needs. If we keep our focus on the goal, the technology becomes as an asset rather than a liability. Digital transformation is not a goal but a continuous process.

June 27, 2019
-

Heroku: An Awesome PaaS Platform

Category : Development , Microservices

The days that companies measured productivity by the amount of time worked and number of lines of code written are long gone. In the fourth industrial revolution, businesses do not have the luxury of spending years on developing products. The audience and market are moving so fast that companies have to continuously innovate and deliver new products and services to stay in business.

Cloud services providers who offer various “as a Service” products also have to continuously evolve. We are in a cloud native microservices and serverless era. One such “as a Service” product is Heroku. Heroku is a Platform as a Service (PaaS) founded in 2007 and acquired by Salesforce in 2010. There are dozens of alternatives the various “as a Service” offerings that are available. Some of them need expertise while others leverage existing talents. We will keep our focus on Heroku for this article. Heroku is one such product where a developer who knows how to commit a code can deploy a scalable application with a single commit.

Many of us might have heard about two pizza teams and how you should keep the number of team members responsible for a service to a minimum. With Heroku, you can start with just a couple of engineers and add more as needed. A lot of focus over the past few years has been on building a minimum viable product (MVP) made popular by the lean movement. The time period we are in is even more faster. Why just build an MVP when you can build a great application with a team focused on business need and spending less time on platform, infrastructure, and even DevOps?

Should You Orchestrate Containers?

Businesses no longer have to buy servers and install operating systems. If you are still doing that, it is like living in the era of CRT monitors and manual typewriters. Provisioning a server with the OS and all the libraries is just a click and a few seconds away. In a similar way, running scalable applications should not mean every business needs to learn how to deploy, orchestrate and manage the containers in every single cloud service provider.

Heroku DevOps Support

With Heroku, a single commit by ‘git push heroku master‘ can deploy your Java, Ruby, Python, Go, Node and many other languages into scalable cloud infrastructure.

Heroku provides various DevOps support with its toolsets. Heroku has its own tools such as the ones listed below:

One of the core contributions of Heroku to the community is the buildpacks. Buildpacks make it easy to deploy applications. The auto-detection, build, and deployment of applications means you could literally deploy your code to a staging environment even without having all the SDKs installed locally. The point here is to emphasize the simplicity of buildpacks and not a recommendation that you develop without the right tools. If you have to make a small change to your code, you could even edit and commit directly from your Github and trigger a deployment via pipelines.

Heroku teamed up with Pivotal in 2018 to come up with Cloud Native buildpacks. More on this can be found at https://buildpacks.io/.

Productivity means developers focus on what is more important to satisfy the business need. If a business does not adopt the best practices, it only means that they get less benefit and more frustration out of their team.

Heroku is available in various regions and via pipeline you could easily deploy the app to multiple regions.

Heroku For Compliance

The businesses that require HIPAA compliance, PCI compliance and other compliances can make use of Heroku Enterprises. Heroku provides private spaces that are only accessible via VPN and within VPC. Also Heroku provides PrivateLink to AWS resources. Heroku itself runs on AWS servers and is available in many AWS regions. Heroku may or may not continue to run on top of AWS. But the commitment from Heroku to support VPC/VPN connections to other cloud providers’ resources and on premise seems strong.

Heroku Ecosystem

Since Heroku is a product owned by Salesforce, their obvious focus is on providing integration to Salesforce (CRM) platform and associated products. Salesforce provides Heroku Connect to synchronize data between Salesforce and Postgres database in an enterprise deployment.

Microservices in Heroku

You can run applications in microservices architecture within Heroku Private Spaces or in the much more affordable public spaces. It all depends on the type of the applications that you are running and the compliance need. If you are building applications in Java and are interested in Spring Boot, Spring Cloud Services you could look into JHipster. JHipster provides various tools to build and deploy applications to various cloud providers including Heroku. Spring Cloud relies a lot on the Netflix OSS tools. Netflix may discontinue a project or put it on maintenance mode. Spring cloud has its own release cycles and sticking to them will make sure that you are able to focus on your applications and not worry about figuring out which dependencies are compatible.

Where Do You Start

The focus of this article is to introduce readers to Heroku. You could start by building, deploying and running applications for free. You could choose the computing engine that suits your needs starting at $7 a month per container/dyno.

The best place to start is the Heroku Dev Center. Choose your language, go through a quick tutorial, deploy your application, and feel the power. It is definitely a great experience to run and scale your application without having to worry about SSL, load balancing, OS, sdk, networking, orchestration or setting up monitoring. Heroku provides a web dashboard as well as a powerful CLI tool. You can also find a lot of addons at Heroku Elements Marketplace to enhance your application. A lot of them are available with a free tier as well.

Do Not Stop There

A blog on Dev.to comparing AWS and Heroku is a quick read on how Heroku provides added value compared to AWS.
You could benefit from the power of running microservice apps on Heroku along with the other services out there. You do not have to restrict yourselves to the Heroku elements. You could combine the power of Heroku along with AWS and other cloud provider offerings. As an example Okta developer provides a free tier with up to 1000 monthly active users to get you started with authentication. In one of the applications that we developed, we leveraged AWS Lambda function to recognize and parse documents (OCR using tesseract), and another function to support zipping documents for download. The idea is that you could build an awesome application that costs less than a $1/month per user with the ability to scale as needed. There are other competing products such as Pivotal Cloud Foundry, but Heroku is a developer-friendly place for small and medium size businesses to get started.

Published: June 27, 2019

May 22, 2019
-

Liferay: In A Serverless and Microservices Era

Category : Liferay , Microservices , Serverless

In the era of microservices and serverless architecture, it is essential to evaluate if you need to build or buy a software. A decade ago, there was still a lot of push back against virtual machines (VMs) for production servers as they were considered the cause of performance issues. One easy solution at that time was to scale vertically by adding more vCPU and memory. That is not the case anymore. Organizations have not only adopted virtual machines, they are also moving towards containers and serverless. Applications don’t have to be built and deployed as a massive piece of software anymore.

Modular Monolith

As tech giants were sharpening their skills related to microservices, containers and serverless, most businesses were still struggling with modular monolithic applications. The reason they are called modular monolith is because the applications are written as modules but deployed as a monolith.

How can you tell if you are running a modular monolith? In order to figure that out, you should evaluate a few points. The first is that if you are upgrading the application, all the services will be down during that process. The second is that if you need to scale parts of your application, you have to scale the whole application server. One more indicator that you should pay attention to is that your application demands that you use certain programming languages and constructs.

Trend

As of now, many businesses have adopted or are considering their options with microservices and serverless architecture. They do have their own challenges when it comes to orchestration, monitoring and management. It is a different problem to deal with than with the traditional modular monolithic applications. Many tools make it easy to deal with microservices and serverless architecture. Several of them support a single CLI command to deploy the changes to any environment. In the serverless area, Amazon has its own AWS SAM CLI while Serverless, Inc has a serverless framework.

Cloud technologies adoption is becoming common in sectors such as government, healthcare and payment card industries.

What Are We Solving? Is There A Business Driver?

The goal is not to adopt technology for technology’s sake. The goal should be to solve the business need in a cost-effective and timely manner while meeting the demands of ever-changing requirements. We need agility and speed while simultaneously running a highly available application. It is important to keep our eyes on the goal. If a modular monolith solves your need really well, you may want to keep it. But let’s not allow the love for our legacy applications keep us away from innovating in business and technology.

How Do We Adopt?

Adoption takes time. It does not have to be an all or nothing approach. The best way to start is to explore the options for some parts of your application. If you have to parse documents, scan documents, analyze text or video etc., it may be better to externalize those to use the serverless offerings than to deploy and manage those services yourself. Traditionally applications will run command-line tools in the same application server to perform a whole bunch of tasks. The issue with this approach is that you are forced to scale the whole application layer when you have to scale these other processes that are competing for the same resources. A piecemeal approach may be a good starting point.

Is Liferay a Modular Monolith?

The above prelude is important for the following discussion. It is very likely that some of the readers may not even have heard about Liferay. Liferay is a Java based digital experience product that is primarily used to build intranets, customer portals, dashboards and public facing sites. As a product, Liferay has been around for more than 15 years. I have spent more than a decade with Liferay since I was introduced to it in early 2007.

Liferay has evolved over the past decade, yet it may fundamentally look the same when it comes to the deployment architecture. Let’s quickly go over a few points:

Search. A decade ago Liferay was using Lucene by default and supported Solr and other engines for search and index of documents. Now it uses elastic search by default while providing support for Solr.
Database. Liferay runs on a relational database, but you could develop applications (portlets) that use their own datasources. This remains the same since founding. Liferay did remove some of the supports for database sharding at application level.
Deployment Architecture. In a high availability environment, Liferay instances are deployed as clusters with all the instances sharing the same database and data storage. Plugins that are developed can share the same database or connect to external services and databases. The major change for enterprise customers is that Liferay has recently started supporting the elastic licensing model where you could increase and decrease the number of instances while paying only for the additional time. In earlier versions the request for license was through a ticketing system. This has changed since the introduction and evolution of the Liferay Connected Services plugin.
Vertical Scaling. It is very common for Liferay installation to demand a more powerful application server configuration as a lot of heavy lifting happens at this layer. As an example, all the document parsing, conversion etc. happens in the application server and only the indexed document is pushed to the search engine. Also, all the content images that are being stored are rendered and cached at the application server layer. It is technically possible to externalize the cache with external caches.
Plugin Portlet Development. Portlets are generally written in Java or a few Java frameworks such as Spring MVC, JSF etc. In the latest version of Liferay, you can write portlets using Javascript frameworks such as React, Angular etc. Liferay supports bundling the JS application and deploying it to the server or running it as standalone JS application using Liferay remote services. It may be very convenient to bundle all the Javascript and deploy it to the application server. Deploying in such a manner means your application server is also the web server serving a lot of Javascript and CSS.
Services. Liferay has supported exposing the remote services via SOAP, JSON APIs for a long time now.

Various aspects of Liferay have evolved over the past decade, yet it may fundamentally look the same at a high level. Liferay deployments resemble more of a modular monolithic application when it comes to scaling and upgrade. Is there a way to address some of the concerns?

Microsites As An Option

One way Liferay solves some of the scalability and availability needs is via microsite architecture. As an example, we can see how Liferay addresses their own needs. Liferay.com probably started as a single application server which later evolved into a cluster. Various needs for separation of content and access were provided through communities and memberships in a single application cluster. One disadvantage with this approach is that you have to scale the whole system vertically and horizontally to support the growing user base. Another major challenge with a single application cluster is that an upgrade will affect all types of users, sites, and communities.

One way to solve the scalability and upgradability challenge is to run separate clusters of various microsites such as help.liferay.com, web.liferay.com, partner.liferay.com, community.liferay.com, dev.liferay.com etc. They all are tied together via SSO, but exist independent of each other. Typically, if your departments are big, they may want to manage and upgrade their own microsites. This would result in multiple versions of Liferay running within the same organization. This could result in the creation of the very silos that organizations are wanting to prevent. As we all know, the organization’s culture will reflect in the way the teams talk to each other.

Build Or Buy

If you have the capability to develop greenfield applications, you should definitely look into your options that are not constrained by a platform. Do you need a blog or are you trying to build a site like https://medium.com? Is your need for service easily fulfilled by an existing platform or do you have to customize the platform heavily?

It all depends on your business needs. If you are going to spend a significant amount of time and money to customize a product, it may be worth looking into building greenfield applications. Also you could take a hybrid approach where your application leverages functions as a service and other serverless features as needed. If your application has a need to export a lot of files as part of the regular use, it would be wise to run this zip process in an AWS Lambda function or as a separate microservice in an asynchronous way. Running such processes in an asynchronous way within the same application server may not be suitable for your use case. It is better to free up your application server resources so that it can better serve other requests.

What’s Next?

I wish I could cover everything in a single article. But that would become a modular monolithic article. I hope to cover more on this topic in future articles. If there is something that interests you specifically, please comment.

Published: May 22, 2019

Category Archives: Microservices

-