Do you wonder why applications you rely on every day seem to take forever to offer the enhancement you needed yesterday? Or why after an upgrade, you discover a strange defect in a product you've been using reliably for years? Have you noticed it’s sometimes surprisingly expensive for vendors to integrate their products to one another, for what seems like a simple task?
Looking back: Monolithic applications
All of these issues may be due to applications that accumulated countless features and were built with a monolithic architecture. A monolithic application is composed of hundreds of moving parts and is compiled and delivered as a single massive product. This is how a lot of big software packages were created and deployed throughout the history of computing.
Applications typically start as small programs and grow bit by bit as new features are added. Over time, they eventually evolve into large programs consisting of a web of highly interdependent pieces. This is a completely natural way for applications to start out, but as they increase in scope and complexity, the tightly bound pieces lead to some serious drawbacks:
- Difficulty adding new features or update existing ones
- Harder to find and fix bugs
- Slower to install and tough to manage
- Fewer reusable pieces, so new solutions take longer to build
Now, this doesn’t mean a monolithic application can’t be well-organized internally. In fact, many are made up of well-designed pieces. The problem is those pieces are highly connected and can’t stand alone. Also, monolithic applications typically have a single, sizable database at their core and several large code libraries, which are cumbersome in aggregate and not easily reusable by other applications.
Good software engineering practices suggest that managing the inevitable increase in complexity requires breaking down applications into formal components, each corresponding to a functional area.
Looking forward: Microservices
Over the years, many ways of achieving this functional componentry have arisen, but one approach has risen to the top: microservices. For the last few years, they’ve become a popular way to break up the monolithic application design.
A microservice is an executing program that is entirely responsible for a small set of functions. In essence, this design takes the many functions normally packaged together in a monolithic application and breaks them up into several individual services that can be executed and updated independently. This kind of a solution is much easier to manage and maintain. Think of a string of Christmas lights where only one bad bulb has to be replaced vs. the entire string going out when one bulb goes out.
Another important advantage of this approach is that when a product enhancement is complete, it can be made available for use right away, simply by upgrading one microservice. And if several applications leverage that microservice, they implicitly acquire this enhancement too. This saves both development and datacenter time, and the new feature will function consistently across these applications, creating a better user experience.
The term micro implies each microservice has a single purpose. But as enhancements are requested, it requires discipline to prevent microservices from becoming monolithic themselves. If you need a new set of functions, it is time to create another microservice. This functional separation can be leveraged in cloud deployments. And because certain functions are in higher demand than others, each microservice can be independently executed and scaled to meet consumers’ needs.
Over time, a software system will consist of dozens of microservices. A set of microservices can become the foundational building blocks of a new kind of software platform on which various applications can be developed. These applications can be used by teams within one company or shared across a partner ecosystem. And because microservices are built with open standards such as HTTP and REST, they are readily consumable by all, regardless of their particular technology stack.
What does all this mean for your campus?
Big applications are reaching new levels of scalability and performance as cloud-native microservices become more common. These modern software systems liberate features and make them available for use as soon as they are completed as opposed to being batched up into large and infrequent software releases.
For end users, specialized platform services and their corresponding user interface components provide a consistent experience across a suite of applications. For all of these reasons, college campuses benefit greatly because a platform built of microservices will permit disparate systems to be more easily integrated. Through the use of simple and open APIs, you’ll be able to bring together your school, partners, and vendors into a more unified technology ecosystem.
Vice President, Product Development
David Kelley is TouchNet's Vice President of Product Development; he joined the company in 2017. David is passionate about engineering excellence and the higher education space. Before TouchNet, David was Vice President of Engineering at Perceptive Software/Lexmark where he oversaw the development of products such as Perceptive Content. Prior to that, he was a software engineer and software architect working on products in the financial and health care industries. David holds degrees from the University of Maryland and the University of Illinois.