IT modernization is one of the key focus areas across the federal government these days. With so much emphasis on modernization, there is little attention being paid to software architecture as a means to enable transformation. Most federal IT agencies are faced with a familiar challenge: How do we modernize our software applications and take advantage of the benefits enabled by cloud computing?

The answer may not be as simple as some would think, since most federal agencies are living with rigid, outdated and non-responsive software architectures contributing to significant challenges towards modernization.

Many agencies still have IT systems based on what is known as “n-tier,” multi-tier or layered software architecture. These legacy architecture patterns are from a bygone era when there were no smartphones, cloud computing did not exist, agile was probably still it its infancy and most had not considered the possibility that the web browser will reign supreme as the primary user interface for software applications.

Worse off are agencies with even more antiquated architectures such as mainframe systems, which are well-known for being horrendously difficult to secure and maintain, yet cost an arm and a leg to operate.

These legacy architecture patterns have resulted in monolithic IT systems that are costly, risky and unable to keep pace with the changing stakeholder and user needs. Due to the inherently limitless dependencies between applications, or even software modules, it is quite painful and difficult to deliver enhancements, fix defects and perform timely security patching. Not to mention an innate inability to deliver product features in pace with shifting user needs. With the recent focus on resiliency, legacy architectures are simply unable to scale in a feasible way to be considered high-availability, self-healing and highly secure systems.

The service-oriented architecture (SOA) movement of the early 2000s has largely been declared a failure due to being overly complex, inflexible and difficult to implement.

Agencies serious about IT modernization efforts should not lock themselves into a rigid architecture, such as legacy SOA, unable to change over time or locking the organization to a particular vendor or technology forever.

What is desperately needed is an evolutionary architecture that enables and embraces change through the use of fine-grained services, open standards and application programming interfaces (APIs).

Since the early 2010s, microservices architecture (MSA) have been steadily rising as the most promising best practice for software architectures. MSA is an approach to developing an application as a suite of small services with light-weight messaging through APIs.

Microservices are the secret sauce running behind the giant tech behemoths such as Amazon and Netflix. Even non-tech companies such as Coca-Cola are wholeheartedly embracing microservices for a majority of their software architecture. In a sense, MSA is the rightful heir to the legacy approaches such as SOA, since it embodies the service-based architecture benefits of technology flexibility and business agility, while harnessing the power of modern cloud infrastructure.

The beauty of microservices is that they significantly reduce dependencies between software applications and drive down complexity. This allows developers the ability to easily maintain and enhance software in the technology of their choice. An application or software module that used to be thousands of lines of code can now exist as a collection of nimble and autonomous microservices, each consisting of maybe a hundred lines of code.

Microservices truly enable dev/ops and continuous integration/continuous delivery (CI/CD) since releases can be less risky and be deployed much more frequently as they only impact a small part of the system.

With the growing adoption of cloud computing, microservices finally make it possible to selectively scale applications with heavier workloads; achieving the cloud promise of consumption-based billing. Integration between services is greatly simplified due to much of the complexity residing behind APIs. With MSA, introducing new technologies into an agency and integrating one-off cloud-based software-as-a-service (SaaS) applications into the larger IT environment becomes much more practical and feasible.

One of the many unsung benefits of microservices is the ability for agencies to achieve significantly enhanced cybersecurity posture. Since each service is restricted to doing one thing, the attack surface is reduced and it is simpler for cybersecurity professionals to conduct more thorough code scans to understand the impact of each service.

Since the Office of Management and Budget designated high-value assets (HVAs) and other high-availability systems, microservices are more relevant than ever. MSA offers exceptional resilience and fault-tolerance because each service operates autonomously and failure of one service will not bring down the entire system.

Some of the challenges in successfully implementing microservices will require a shift in traditional thinking. For example, decentralized data management is one of the key components inherent in microservices and can be seen as radical within the traditional IT shop. With the advent of many specialized noSQL database solutions, requirements can now be matched with the appropriate technology optimized for particular use cases. Decentralized data management when combined with centralized data governance will ultimately provide the right balance between data integrity and technology flexibility.

Agencies faced with deciding what to do with their legacy SOA investments should carefully consider modernizing their applications using the “strangler pattern” in a steady and incremental manner. Modernizing the system piece-by-piece reduces the risks inherent in a full rewrite and still continuously provides business value to end users.

While microservices are the current best practice for software application architecture, selecting an optimal service-based architecture resides on a spectrum of granularity. While most experts agree that old-school SOA is no longer the answer, the definition of what size constitutes a microservice varies. What constitutes a good “service” and the size of said service are not set in stone. A good rule of thumb is that a microservice should be no larger than what can be developed within two weeks. The best practice is to right-size microservices to the level of granularity needed to achieve optimal levels of business agility, technology flexibility and customer satisfaction.

Syed Azeem is a career federal IT program manager and digital services expert. He is currently an IT project manager at Department of Labor. Most recently he was responsible for leading the DoD’s Defense Travel System Modernization and Treasury’s Electronic Federal Tax Payment System Modernization efforts.

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.