Government mission evolve because of legislative and policy changes. Also, the citizens expectation of government services to evolve to match with other consumer services and be available where they are, in format they can easily consume. To alleviate such risks, especially from frequent technology revisions, governments need to move towards implementing microservices to be able to adapt to changes fast, continue innovating, and tackle competition without compromising on Return on Investments (ROI) in IT infrastructure. Governments need to look towards implementing microservices to build their digital applications and to keep pace with citizens’ expectations.
But what are microservices?
In the last few years (since 2014), microservices or microservice architecture is emerging to alleviate the way by which software applications are designed as a group of autonomously installed services. Micro, as the name suggests, refers to small and specific services or mini programs built to cater to a specific task supporting a specific goal. These services also use simple application programming interfaces to communicate and interact with the other services, through a lightweight mechanism serving a precise business objective. All these can be integrated to create sizeable/enterprise applications. It is easy to build and deploy them independently as simple services, are highly cohesive and autonomous, resilient and business domain centric, can be scaled independently or with other groups and produced speedily. They work well with the container Docker, and act as a complement to cloud. Also, Microservices are going serverless, which simply implies that the developer can continue to build up the microservice without having to worry about maintaining the server as the server can handle itself. This is also possible as cloud enables/provides a serverless environment.
How did microservices originate?
Technologies used by Google, Twitter, Facebook etc. gave rise to API platforms. They incorporated data sharing and interaction between computer programs. To mitigate damages to API, microservices were established. Microservices began primarily to handle one function of API. If one microservice failed, another could immediately take its place and help the API to continue providing its services.
Owing to microservices, organizations are able to continuously develop their technology stack enhancing the possibility of incessantly delivering large and multifaceted applications. These services connect with each other over HTTP/REST protocols, characterize decentralized governance and data management, rebuild or re-architecture with different technologies while supporting the same APIs. For example, a grants management application would require microservices for GrantsFrontUI, Application Intake, Awards, Status Reporting, Closeout, Audit, Grants.gov interface and financial processing. In such a scenario, all these single services work as microservices for one large application. Microservice architectures are currently being used by organizations such as PayPal, Netflix, Twitter, Google, Uber, Gilt, Amazon, eBay etc and as well government agencies such as GSA and DHS USCIS.
How are microservices effective for a rapid and responsive digital government?
The government services used a single, custom approach, chiefly the monolithic applications. Over time, these became standardized, cost millions, became challenging to modify, did not deliver any value, and became difficult to adjust to the continued newer needs of the citizens. Changing these, meant the application needed to be re-developed, tested, and deployed again. Subsequently, diminutive powerhouses or small software workings called microservices entered the scenario which could work independently and took each task exclusively and effectively.
Government agencies need to provide digital services along with making them speedy, secured and user friendly. Microservices are able to handle a host of unique demands as they are more flexible and agile, and can be made feature-rich. For e.g. a single user id and password could be provided to give access to citizens for using all of the agency’s services without being concerned agency component operating the service. This is especially helpful when the Federal government wishes to upgrade and augment the services largely used and required by the citizens and agency partners, along with enhancing their operational systems. Microservices can also minimize and manage accumulation of technical debt.
Federal agencies can go on to collaborate with each other to build customer/citizen centric mobile applications using microservices by using specific data possessed by each agency. For example, the census data by Bureau of Labor Statistics, or data by Department of Veteran Affairs can aid in developing superior designed and delivered government services. Another example could be of the US Office of Personnel Management where one microservice could tackle leaves, one could handle pays and one could handle retirement services with all the data provided by this agency. In the case of physically challenged, the applications must assist them in completing transactions and locating information easily. And if the US federal government provides an application for vacationing in the national parks, then one microservice could tackle reservations while another could tackle lodging.
Microservices can be used for a consistent look for a familiarity with the application. In a government application, the first version can be developed, and with regular citizen, state, and local government agency feedback, the services can be modified and upgraded (by new developers too as they are small and uncomplicated to understand).
Governance across groups can essentially make microservices a part of the Federal government’s, supporting its main objectives and building citizen-centered mobile applications. The governments’ IT managers must support technical planning, collaborate with other agencies, spot and categorize microservices and sustain their citizen’s hope for providing finer services.