Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

What Are The Most Important Elements of Microservices?

DZone's Guide to

What Are The Most Important Elements of Microservices?

Microservices and DevOps go hand-in-hand. Learn more about their reciprocal relationship in terms of speed and decentralization.

· DevOps Zone
Free Resource

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

To gather insights on the state of microservices today, we spoke with 19 executives who are familiar with the current state of microservices architecture. We asked them, "What are the most important elements of microservices?" Here's what they told us:

Speed

  • Overwhelmingly the benefit for our customers is speed. The microservice architecture plans we develop for our customers emphasize the speed of new feature development, of ongoing maintenance, and of the day-to-day work of deployment and testing. Frequently our customers are fighting against the relative slowness of their own processes at IT, such as change request management and testing. These processes tend to be stable and reliable but highly inefficient, which stifles the nimbleness and market responsiveness that executives desire.
  • Faster development and iteration. Easier to maintain and refactor. Easier to control. Fewer dependencies across teams (we run five), automated test suites, less coordination required, an approach (all well documented with good client libraries), governance groups with different leads from different teams.
  • Scalability is critical. Think about how to structure to scale in multiple dimensions and run on multiple machines. Low coupling and high cohesion between the parts.
  • Easily scalable and deployable.

Decentralization

  • The ability to keep things as generic as possible: every microservice should do only one thing, no matter the message source context, no matter what is next. Splitting big tasks like that is much more maintainable and programming business logics is a lot easier.
  • Microservices are all about autonomy, decentralization, and real-time computing. Operate peer-to-peer using APIs. Graph data, polyglot, real-time event-driven use cases.

Smaller Components

  • Microservices are a way to get data. Microapps are small single purpose unit. Microflow is the process that takes place once the app is activated. Versus monolithic applications with long business processes. Take the app and break API calls into small actions. Part of the architecture shift – still need ERP and CRM but you need ways to be agile.
  • From the software design perspective, everything is normal; however, all designs need to be more formal. There is a need to think through things are a finer level of detail. How to do security to ensure every microservice is safe. You need to be more systematic. It’s a combination of technology breaking into smaller pieces and shipping less code more often. Traditional IT ops needs to be doing DevOps so developers will own the problem if an application is breached.
  • The key benefits are: 1) isolation of responsibility - simpler to build and maintain microservice code; 2) fault isolation - any microservice can crash and restart without causing a service outage; and, 3) fine grain scaling - each service can scale independently and rapidly.
  • The ability to break down monolithic web and mobile apps into smaller components that are easier to manage, maintain, and keep up to date.
  • Move from monolithic code breaking large complicated apps into special purpose apps that align with business goals, have a simpler code base, smaller and simpler components. It’s easier to get developers on board when they don’t have to learn a monolithic app.

DevOps

  • Provide the ability to decouple and deliver application functionality faster with greater stability, agile development and teams to downstream delivery of applications with the ability to recognize the potential around agile and DevOps. Microservices and DevOps go hand-in-hand. There’s a reciprocal relationship. To deliver microservices as a core part of your architecture you need the component production of DevOps – agile, CI, CD. Decoupled apps are difficult to deliver without DevOps. Reverse relationship to implement DevOps to deliver faster you need to decouple apps into smaller elements.
  • We work on the big picture helping companies make the digital transformation – legacy organizations with monolithic apps. Typically, lots of entangled monoliths. Methodologies and approaches for big structural changes. There is a strong affinity between DevOps and microservices. Microservices addresses the architectural bottleneck moving towards decentralization. Empowerment of smaller organizations with less coordination – greater autonomy.
  • Culture. Evangelists have done a good job of explaining the benefits of microservices. Smaller teams with easier challenges to be overcome. Cultural shift is a learned experience to a more distributed network. Change in mindset and processes. Good communications to ensure everything is working together. Team enforces security. Big chunk in DevOps and adopting DevOps is important to ensure developers and operations communicate in an agile and collaborative way. Make sure to update the test cycle, communicate that you are doing do and how to iterate.
  • Change the security model. From a single session with a monolithic application to API sessions. Build for agility, alignment to problems and teams. Digital transformation. Strong need for a customer identity platform.

Other

  • Portability is the greatest advantage. We get the same practical benefits of a Virtual Machine, but the transfer size is usually between 0.02GB and 2GB. A VM starts at 2GB and will often exceed 20GB. Because they are 1/100th the size to move around, it makes it practical to transfer over even spotty internet connections and we can do it while working with a client rather than as an overnight download. This speeds up development time when on-site and improves our customer's perception of us. After portability, consistency is a big benefit. Containers are most popularly used in a Linux environment, and the problem with Linux is that every distribution is different. These differences need to be accounted for when you're doing security auditing and compiling new software. If you use a container, then you bring that development environment with you. It also makes it much easier to address CVEs (common vulnerabilities and exploits) because you can fix it on your development environment, type in two commands, and then that security patch is available to everyone.
  • It is our strongly held belief that microservices would benefit the most by having their own autonomous, local data source. Not only does it make microservices perform faster, it gives them proper scoping so that they’re not doing too much ‘behind the scenes’ thereby keeping them simple and easy to use. This is especially true when you take into consideration the fact that you can build microservices to use a replica of a master data source, the way it’s available in Oracle Berkeley DB and NoSQL database, not to mention Figaro. Why strain your network with queries when you can have your entire data source available within your runtime?
  • There are three basic elements of microservices that are crucial: 1) Microservices are agile. Let me paint this as a story. As a Chief Risk Officer, I have my team expose a scorecard as a service to be used as part of the credit underwriting process. The Chief Operations Officer is in charge of that process. As part of the exposure of the scorecard, we agree that if the underwriting process passes seven variables to the scorecard service, the service will return as a score. As long as I don’t violate the contract - give me seven data points, and I’ll return a score - it doesn’t matter to the underwriting process how the score is calculating. This means, if the risk team discovers new data sources they can leverage, or if a new scoring model is created, they are free to implement it; that change will not negatively impact the underwriting process. This level of agility means risk professionals can quickly adapt to a changing risk landscape. 2) Microservices are resilient. In the example above, as long as the service that is exposed adheres to the original contract, the processes that rely on the service will not break. Both sides of the contract - give me seven variables and I will give you a score - are able to best meet terms in the contract. The underwriting process can retrieve the variables any way deemed best, and the scorecard service can calculate the score as deemed best. As long as the contract is adhered to, neither is impacted. 3) Microservices are open. At this point, most microservices are designed to leverage REST as the mechanism for data exchange. REST is showing itself to be secure, lightweight, and flexible. This open nature represents huge potential in building end-to-end processes that best meet the operational needs of the enterprise.
  • There are different variations of microservices. What we are noticing is when people think about a microservice architecture, they often think all your microservices will be a single type that is business logic heavy requiring custom code. With some of our web-scale customers we see that, however, this is not the only type. In fact, most enterprises will have integration logic heavy microservices. They have to connect to SaaS applications and legacy back-end systems. There is a need for these connectivity microservices. We expect there will continue to be a mix of these.

What are the most important elements on microservices from your perspective?

Here’s who we spoke to:

  • Thomas Butt, CTO, CardCash
  • Matt McLarty, Vice President, API Academy, CA Technologies
  • Brian Dawson, DevOps Evangelist, CloudBees
  • Lucas Vogel, Founder, Endpoint Systems
  • Ali Hodroj, V.P. Products and Strategy, GigaSpaces
  • Job van der Voort, VP Product, GitLab
  • Kevin Sutter, MicroProfile and Java EE Architect, IBM
  • Sandeep Singh Kohli, Director of Marketing, MuleSoft
  • Karl McGuinness, Senior Director of Identity, Okta
  • Ross Smith, Chief Architect, PITSS America
  • Mike LaFleur, Director of Solution Architecture, Provenir
  • Gianni Fiore, CTO, Rebrandly
  • Peter Yared, CTO, Sapho
  • Sha Ma, V.P. Software Engineering, SendGrid
  • Keshav Vasudevan, Product Marketing Manager, Swagger/SwaggerHub, SmartBear
  • Chris McFadden, V.P. Engineering and Operations, SparkPost
  • Christian Beedgen, Co-founder and CTO, Sumo Logic
  • Todd Millecam, CEO, SWYM Systems, Inc.
  • Tim Jarret, Senior Director of Product Marketing, Veracode



Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:
microservices ,containers ,devops ,scalability

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}