The best way to appreciate key concepts involving digital transformation is to look at real-world examples. In a recent Kong webinar, I sat down with Solutions Engineer Ahmed Koshok as he reviewed several real-world case studies that help illuminate the role of microservices in making digital transformation successful for organizations.
The case studies included Papa John's, NextJ Systems, and Yahoo! Japan. Each company used a different approach to implementing microservices, and their stories illustrate the key issues that all companies must address in their own implementations.
Let's start with the definition of digital. Anything digital can be reproduced with integrity, as it has automatic error correction and near-instant access. Koshok reiterated that, just as CDs, MP3 audio technology and iTunes digitized music, a key goal of digital transformation is to convert analog capabilities and functions into a digital form.
An example of process digitization is when Netflix stopped shipping DVDs to customers but instead began streaming movies on demand. Sure, the DVDs were digital, but their delivery was analog, using envelopes over snail-mail.
As businesses digitize, they will find that they have numerous processes that can be digitized - and that's where microservices come in.
Microservices in Digital Transformation
In the earlier days of computing, enterprise processes were run on mainframe computers, which are digital but have their own limitations and constraints. As Koshok explained, that's why a mobile banking app might not be able to connect to the bank on Sunday mornings - because the mainframe is taken offline for maintenance, for example. That's what happens if you have a big monolithic application, he said. Changes need to be grouped together and made all at once; it is not agile.
By embracing APIs and microservices, a business gradually breaks down and compartmentalizes components and makes them accessible and reusable, therefore more agile. In this context, agility is the ability to quickly capture new opportunities by breaking monolithic applications into component functions that can be easily assembled and reassembled as needed.
Agility is not free, however. As a business creates more and more microservices and APIs, maintenance overhead comes with them. And latency may increase because different capabilities underpinning a microservice may be located all over the enterprise, unlike in the mainframe scenario where all capabilities are executed on the same machine.
Three Types of Microservice Connectivity
There are roughly three main types of connectivity patterns for APIs and microservices, according to Koshok.
One is at the perimeter. An example would be a website that exposes certain information or processes from inside the organization to an outside consumer. This is the well-known B2B use case.
Another type of connectivity is internal – inter-application connectivity. An example would be teams in different departments that need to talk to each other and share information or functionality.
The third type of connectivity, or pattern, is within applications themselves – intra-application connectivity.
Essentially, the three connectivity types are: perimeter, between applications and within applications.
Microservices may be housed in the cloud - and that raises some other issues that businesses must address. Security is perhaps the first and most important. As an example, organizations could consider establishing a virtual private network (VPN) to help secure the connection to the cloud if they do not want their services to be publicly available.
Another concern involves architectural freedom - the ability to move resources from one cloud provider to another, avoiding vendor lock-in. All three connectivity patterns will eventually need to work in the cloud. Therefore, organizations will need to work to distribute, or break down, their applications and workloads and make them deployable in an automated way such that they become portable.
It is not possible to overstate the importance of good security practices when implementing microservices and APIs. The classic information security pillars still apply in this use case.
As Koshok explained, these include:
Confidentiality: No unauthorized party may see or know the information being exchanged unless they are supposed to. That is, the communication is confidential.
Authentication: Confidence in determining the identity of parties involved in a communication.
Authorization: Scope of access for a user or party based on identity or lack thereof.
Availability: The degree to which a service is resilient in the face of peril.
Traceability: Includes monitoring and logging for forensic or posterity reasons. Artificial intelligence can make this capability more powerful still.
Compartmentalization/segmentation: This involves establishing limits, fences or scopes with the intention of restricting unnecessary access. Compartmentalization can be used to restrict service to only communicate with certain other services.
Integrity/non-repudiation: Once a communication or transaction is completed, neither participating party in a transaction may deny their involvement or that the data exchanged has been altered without their knowledge.
As Koshok reviewed the two real-world microservices case studies on the webinar, one of the issues he discussed was the security implications of each case study.
The Papa John's case study involved a company that had previously customized connectivity to several different partners. Delivery services were typical partners for the pizza company.
Although these connections generated a considerable amount of business, they had become a bottleneck and had significant associated overhead, which meant that the company could not deliver experiences as speedily as desired.
Digitizing services and making them available for partners to consume would not only help Papa John's business; it would also spur partners to do more business with the company.
To make this happen, Papa John's had to determine which capabilities would generate the most value if they were made available externally. The company developed metrics, reports and dashboards to do this based on the 80/20 rule: the rule that says people wear 20% of their clothes 80% of the time or make 80% of decisions in 20% of meetings. The same rule holds true for external APIs.
Once the most critical APIs were identified, Papa John's was able to move them to the cloud to make them more scalable.
As Papa John's worked to implement these plans, security was a top concern.
Of the seven pillars, confidentiality was particularly important, considering the company's multiple partners. Each partner should only know what its own customers ordered. Traceability and compartmentalization also were critical.
NexJ Systems provides customer relationship management technology within the finance and insurance industries. The company wanted to reduce API development time, which was driven, in large part, by cross cutting concerns such as imposing rate limiting caching or adding logging capability.
The solution was to empower internal people to develop APIs by giving them the right tools and the right environment. This required standardizing protocols and standardizing the way APIs are developed, secured and deployed.
Other goals were to avoid huge requirements lists, to support the three different connectivity patterns discussed earlier and to automate deployment configuration.
Of the seven security pillars, confidentiality was a key concern for NexJ Systems. Even when developers are internal, a business should still use a zero-trust approach, and connections should be encrypted, Koshok advised. Compartmentalization and traceability also are critical, even for internal developments.
The third real-world digital transformation case study comes from Yahoo! Japan. To maintain market leadership, Yahoo! Japan began transitioning towards microservices to accelerate service development and deployment. Consequently, Yahoo! Japan needed a new API platform to centralize its portfolio of APIs and to improve the security, availability and performance of its services.