Architects help define the process guardrails and technical capabilities needed to execute on the digital strategy of business, which often includes evolving web apps and API infrastructure—API gateways, service meshes, and developer portals—into cloud-based platforms.
In practice, there are “lift and shift, “refactor” (or “re-architecture”), and “replatform” approaches, and the decision on which architectural journey to take depends on several factors. For example, how much coupling and cohesion can be safely implemented. A highly cohesive and loosely coupled API should be the goal, as it provides a stable interface and level of abstraction—protecting the system from a cascading effect of implementation modifications that would otherwise be needed when a single design change is made. This allows the different parts of the architecture to evolve independently.
Decomposing an existing monolithic application into microservices and migrating it to the cloud is a prudent choice for modernization, as this approach enables API providers and API consumers to evolve their systems more effectively.
Here we will explore a hypothetical case study where an organization modernizes a legacy system by refactoring it into an API-based architecture and replatforming it for the cloud.
What does it mean to modernize a legacy system? A common step in any digital transformation journey is to provide the right touchpoints for customers to transact, which, at a minimum, means creating a mobile app. But there is more involved. In the new digital economy, time-to-market pressure has rapidly increased the number of third-party integrations, as organizations “Build, Borrow, or Buy” to grow their digital mindshare and customer base.
If we look under the hood for how modernization is done in practice, we find that it involves both process and technology—namely automating the deployment and enhancement of systems for continuous delivery and verification (process), and evolving legacy web apps toward API-based, service-oriented architectures (technology). Additionally, API infrastructure such as an API gateway helps to ensure effective deployment into a cloud environment through robust traffic management and security capabilities.
Here we analyze a hypothetical case study for such a digital embarkment involving two phases:
In our hypothetical example, a conference system supports functions such as creation of an Attendee account (create account), review of available sessions (review sessions), and booking attendance (book sessions). The customer interacts with the conference system via a web browser. For example, to book a conference session:
Under the hood, the customer interacts with a web application, which sends API calls to the conference application. The conference application uses SQL to query the backend datastore:
Several requirements are driving the need to modernize the legacy conference system:
A high-level plan is put together:
Steps are taken to refactor the Attendee component into an independent service. The conference system now has two traffic interfaces:
Then, an API gateway is deployed to facilitate scalable, maintainable, secure traffic management including SSL/TLS termination, authentication, and rate limiting:
Next, a service mesh is provisioned to repurpose the Sessions functionality from the legacy conference system into a new Session service. A service mesh provides fine-grained control of routing, ensures reliability, and efficiently brokers traffic for service-to-service API communication to facilitate viewing and booking of an Attendee’s sessions:
Finally, it is time to migrate the Attendee service and API gateway to the cloud. This approach avoids major rework while taking advantage of cloud-native services as the organization migrates away from its existing on-premises infrastructure: