For fast and responsive digital government, why not microservices?

Commentary: Pete Eichorn, director of technology for NIC, says modular microservices are the answer to the slow software development cycle found in many agencies.

Microservices have a big future in digital government.

Digital government services have been primarily built using a custom approach. This can produce enormous code bases that must be maintained. The complexity of custom code can make it difficult to reuse much of the code base and limit the ability to adjust quickly to fluctuating constituent needs. Even small enhancements or fixes mean the entire application must go through another lengthy development, testing and deployment process.

Enter microservices, little powerhouses that have the potential to change all that.

Microservices are small software components that can operate independently. Each one carries out a specific task, such as verifying addresses or running an application’s user profile functionality. Using APIs, microservices can “talk” to each other, and therefore, they can be constructed to work together in a single, cohesive application to achieve big-picture business goals.


While traditional code deployments are like a brick wall, microservices are like interlocking blocks that can be put together in limitless configurations to create larger, smaller or more intricate designs. A block can be removed or replaced without compromising the integrity of the overall structure. How the blocks work together is entirely flexible, just as microservices are within applications.


Having become accustomed to a Google/Amazon/Twitter/Netflix digital environment, citizens and businesses anticipate comparable ease and speed when they interact with government — no matter what devices they’re using. Any government agency that wants to meet constituents’ expectations should begin thinking about microservices as a means for delivering intuitive, simple-to-use interactions. Here’s why:

  • Microservices speed up development. Once they’re established, microservices are easy to maintain and scale, and they can be reused in new applications, even if they’re written in different programming languages. They typically are molded by business needs, rather than technical ones. Thus, they require less translation between the technical and functional perspectives. Further, they usually are supported by technologies and processes, like automated testing and continuous integration/continuous deployment, that build in speed and agility. These attributes combine to expedite development and deployment of digital government services.
  • Microservices give constituents a better experience. With the pace of technological change, it can be difficult to keep up with custom-built
    apps. Microservices allow government agencies to introduce new
    applications with basic functionality and frequently add incremental
    enhancements. Because the process of improving the application isn’t
    arduous, agencies can actively seek constituent input and respond by
    quickly delivering feature-rich upgrades. This process powers a virtuous
    cycle that makes constituents feel valued. They can
    enable consistent look-and-feel and functionality across multiple
    agencies. For example, by sharing single sign-on services, agencies
    could permit constituents to create just one ID and password to access
    all of the state’s or municipality’s services.
  • Microservices help government manage technical debt. When it comes to enhancing legacy applications, government has a dilemma: build fast to
    be responsive to a waiting public or build with quality? The end result
    is technical debt — a “rob Peter to pay Paul” scenario that complicates
    the process of making future enhancements. Microservices can minimize
    the accrual of technical debt. By separating an application into
    microservices, agencies can enhance the components that are most
    important to users and to their own business operations, quickly and
    with quality.



Microservices will change the future of government IT. That said, there are some considerations to take into account with this approach:

  • Microservice applications are not centralized. Multiple teams may be creating and maintaining the components, and those teams may have competing priorities and deadlines. A state CIO or other leader will need to coordinate planning and set a single vision for multiple agencies so the teams can achieve the common goal.
  • When applications are comprised of microservices and one doesn’t respond when it’s called on, service may be disrupted. Development and
    technical operations teams should decide in advance how they will
    monitor the microservices’ “health” to maintain operational stability
    and optimum performance.
  • Moving from a monolithic to a microservice approach may require developers to learn new skills. Leadership will need to help developers
    understand how a microservice strategy supports the agency’s goals and
    allow time for the learning curve to be achieved.

Of course, with the right vision, tools, automation and knowledge, these challenges easily can be addressed. Constituents’ expectations of fast and flexible service delivery have put government at an inflection point, and agencies must develop applications differently than they have in the past. Microservices solve the development problems government needs to solve and are well worth investigating.

Latest Podcasts