Is Microservices Architecture the Silver Bullet? Mary Grygielski at Scalac’s Event
We invited Mary Grygielski, who works as a senior developer advocate at IBM and is the Chicago Java Users Group President, to Scalac’s event “Between Business & Tech.” The digital conference platformed six speakers who shared their experiences in creating microservice-based architectures. Follow this link to watch Mary’s talk or see the whole conference.
Mary primarily works in the Java, open-source, cloud, and DevOps domains with Java-based products like Open Liberty, MicroProfile, and Jakarta EE. In addition, she has over twenty-five years of software engineering and software architecture experience in both product development and the development of enterprise applications.
Dev teams implement microservices to solve the challenges of working with service-oriented architecture (SOA) and monoliths. Mary outlined the difficulties of monolithic architectures and SOA in her presentation. She also talked about the history of microservices and asked whether cloud-native programming and microservices can coexist. Finally, Mary addressed her title question – can microservices be the silver bullet?
Architectures Utilized Before Microservices
Mary began her presentation by taking a look at the architectures that dominated the development space before the introduction of microservices.
Monoliths
Monoliths are single, comprehensive, and encapsulated services. Mary identified several difficulties caused by them:
- Monoliths rely on large, complex codebases with many business modules, especially when it comes to enterprise systems, an area where Mary has extensive first-hand experience.
- Using a monolith complicates the deployment process because dev teams must ensure all their developers are synchronized.
- All monolithic components must be lightweight because they have tightly coupled dependencies.
- A single point of failure can affect the whole system.
- Monoliths can’t handle the fast-paced development processes of the cloud-native era.
- They have an unclear integration or interface because elements are tied together.
- Monoliths complicate replication and error management.
- Scalability is difficult to achieve using a monolithic system.
Mary observed that monoliths cause many development challenges. However, there are some positives to monolithic systems. In particular, teams don’t need to worry about network latency because the whole codebase is contained.
Mary then moved on from monoliths to service-oriented architectures (SOAs) and enterprise service buses (ESBs).
Service-Oriented Architecture (SOA) and Enterprise Service Buses
Before the introduction of microservices, developers utilized SOAs and ESBs. An ESB is a type of middleware that creates a system of communication between front-facing software components and the architecture backend. In addition, ESBs perform reusable integrations and translations.
ESBs were the primary driver of SOAs. However, ESBs aren’t the only method of implementing an SOA.
Mary noted that SOAs have some positive features. However, they rarely meet the requirements of current cloud-native applications.
Like microservices and monoliths, an SOA represents another way of developing an application.
Mary described the benefits of using SOA over monoliths:
- SOAs have high reusability.
- Stateless services using HTTP are fast.
- SOAs offer interoperability. A variety of protocols are available, such as web services description language (WSDL), that allow developers to describe their interface very clearly. In addition, dev teams can utilize different languages, clients, and tools in their systems. For example, teams can use the simple object access protocol (SOAP) or HTTP.
- SOAs have contract-based interfaces like WSDL.
- They are scalable due to clustering and load balancing.
- SOAs are easy to upgrade.
While SOAs have several positive qualities, Mary acknowledged there are drawbacks:
- SOA communication is dependent on the ESB, which creates the possibility of a single point of failure.
- Service granularity can be complicated. Services can range from small to enterprise-wide, and many services are linked together.
- SOAs lack speed because they favor the sharing of resources and the services access the same database. In addition, if dev teams implement their infrastructure incorrectly, it can create a bottleneck.
After outlining the benefits and drawbacks of SOAs, Mary proceeded to discuss microservices and their history.
What are Microservices?
The term “microservices” refers to a newer architectural style that’s a variant of service-oriented architecture. Microservices arrange an application as a collection of loosely coupled services with fine-grain, lightweight protocols.
A diagram of a simple microservices architecture.
As seen in the diagram above, dev teams usually use a representational state transfer (RESTful) application programming interface (API) for connection to the user interface. What’s more, services are independent, with their own databases and resource management protocols.
A Brief History of Microservices
The label “microservices” was first used in March of 2011 at a workshop for software architects hosted by ThoughtWorks. James Lewis, the architect leader, presented an introductory talk. By the end of 2013, the tech industry had grown sufficiently interested in the concept and it began to gain traction.
In 2014, Martin Fowler, also from ThoughtWorks, gave the first official presentation on the subject of microservices alongside James Lewis.
A quote by John Lewis and Martin Fowler.
Cloud-Native Systems and Microservices
Cloud-native computing has undergone rapid change and expansion in recent years. This change encompasses key developments of more general cloud computing capabilities.
In the 2010s, when cloud computing premiered, developers began to utilize cloud infrastructure. Mary asserted that these cloud systems worked well but also placed limitations on application functionality. This was a problem because enterprise applications tend to be integral to the day-to-day operations of large organizations.
On the other hand, cloud-native systems do “extend” the cloud to an extent so that it can support enterprise-level operational systems. They form the basis of a highly decentralized approach to application development and maintenance.
Developers at cloud application platform Heroku designed a 12-factor set of guidelines for using a cloud-native system. Mary briefly outlined each point on the list:
1. Codebase: Developers should store code in one codebase that is versioned and deployed often, allowing teams to trace their code easily.
2. Dependencies: When running a system, developers must manage many different layers of functionality, which should be explicitly declared and isolated.
3. Configuration: Store config in the environment.
4. Backing services: Treat backing services as attached resources.
5. Build, release, run: Strictly separate build and run stages. DevOps helps to make the whole cloud-native system efficient. Development teams should start with a continuous build and continuous integration. Lastly, teams should use deployment to speed up the entire cycle.
6. Processes: Dev team should execute applications as stateless processes. Stateless processes are key because they are agile, and developers don’t need to keep track of data.
7. Port binding: Export services via port binding.
8. Concurrency: Scale out via the process model.
9. Disposability: Services should execute well and maximize robustness but also launch quickly and shut down efficiently.
10. Logs: Treat logs as event streams.
11. Dev/prod parity: Keep development, staging, and production as similar as possible.
12. Admin processes: Run admin/management tasks as one-off processes.
Microservices conform well to these guidelines for cloud-native applications as they decouple the different aspects of systems, like the logging and admin.
After covering these points, Mary then moved onto the question at the core of her presentation: “Is microservices architecture the silver bullet?”
Is Microservice-Based Architecture The Silver Bullet?
Unfortunately, Mary doesn’t believe microservices are a cure-all solution. However, with the right business processes, tools, and development approach, implementing a microservice-based architecture can be effective.
Mary argued, however, that the idea of a loosely coupled, decentralized system is misleading. She covered three main points: network fallacies, business transactions, and cultural change.
What is “The Network Fallacy”?
“The network fallacy” is the false belief that using a distributed system creates a secure, cost-effective network.
One key concern is that microservice networks are always online. High uptime is expensive for companies, especially when developers use a containerized approach or cloud environment billed on a per-minute basis.
Dev teams must ensure that microservices architecture is slimmed down, without any additional burdens, because multi-tenancy servers host many instances of a containerized microservice. To save money, dev teams must ensure each service uses the correct amount of resources, and that services are set to idle when they aren’t processing requests.
What’s more, network latency can increase if a dev team has a very high number of microservices. Java virtual machine expert Kirk Pepperdine has tested various system iterations. His research found that thread schedulers create bottlenecks. If a network issue arises, developers can opt to increase memory but the unit of work must be very precise to prevent services from undertaking additional work.
Thread schedulers are significant because they instruct other parts of a system to execute tasks. With all this in mind, microservice design and understanding the network fallacy are crucial for dev teams.
Business Transactions
When dealing with stateful systems and e-commerce business transactions, complications often arise within applications because of the large number of processes involved. These include ordering, transactions, inventory checking, and more.
In a cloud-native, stateless system, dev teams contradictorily need to maintain the state to fulfill business requirements. This causes developers to go against stateless principles.
It is important that dev teams focus on facilitating business functionality alongside maintaining microservices. Dev teams must ensure data consistency and backup requests at all times so they aren’t lost if any error or failure occurs. It is crucial that information is stored safely while waiting for the next action to take place.
Cultural Change
Cultural change is critical for any dev team moving towards microservices or cloud-native systems. Network changes typically involve many employees who work across different departments, such as ordering, purchasing, and shipping. It is of paramount importance for these departments to function effectively together.
If a business has a poor cultural atmosphere, with teams that don’t get on or refuse to work with each other, serious issues can arise. Animosity and arguments about implementations invariably stall application progress.
Businesses need strong organization and management infrastructure to support architectural changes, along with the right technology. In addition, companies should acknowledge that developers are under significant pressure to maintain existing systems while creating new ones. Despite its complexity, application development should be enjoyable, with a positive, productive atmosphere both in and between teams.
Mary then wrapped up her talk about microservices and outlined several resources for further education.
Additional Resources
Here are several resources for learning more about microservices and cloud computing:
- IBM provides various educational resources about microservices here.
- IBM also offers SOA information as part of their “Cloud Education” program.
- Martin Fowler shares microservices information and industry updates on his site.
- James Lewis from ThoughtWorks has a microservices blog.
- Chris Richardson, who is based in California, shares information on microservices and design patterns here.
- Mary works with the Open Liberty, MicroProfile, and Jakarta EE open source technologies.
- Mary is also open to being contacted on her Discord, Twitter, and LinkedIn.
Conclusion
Microservices solve a lot of the problems created by monolithic systems and service-oriented architecture SOA. There are, however, also challenges. It’s essential for dev teams to cultivate awareness of the pitfalls of microservices and identify whether or not their applications are a good fit. What’s more, understanding the network fallacy, focusing on transaction tracking, and creating a good working culture are all key.
Consultancies such as Scala are available to guide businesses through the complex journey of creating an effective application. Get in touch today to discuss your needs and viable solutions.
See also presentations by other speakers at the Business & Tech Conference. Episode 1: Microservices
Authors
Marketing Specialist at Scalac. At work I value creativity, willngness to learn and good teamwork. Besides, I love to travel, I am piano player and #catlover.
