For fast and responsive digital government, why not microservices?

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.

Benefits

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.

Challenges

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.