In base allo stato cliente, dal tuo account Red Hat puoi accedere al profilo personale, alle preferenze e ai seguenti servizi:
Non ti sei ancora registrato? Ecco alcuni motivi per cui ti consigliamo di registrarti:
- Per poter consultare gli articoli della Knowledgebase, gestire i casi con il supporto tecnico e le sottoscrizioni, scaricare gli aggiornamenti e altro ancora da un'unica posizione.
- Per poter visualizzare gli utenti all'interno dell'azienda e modificarne le informazioni di account, le preferenze e le autorizzazioni.
- Per poter gestire le tue certificazioni Red Hat, visualizzare la cronologia degli esami e scaricare logo e documenti relativi alle certificazioni.
In base allo stato cliente, dal tuo account Red Hat puoi accedere al profilo personale, alle preferenze e ad altri servizi.
Per tutelare la tua sicurezza, se stai usando i servizi Red Hat da un computer pubblico, assicurati di disconnetterti.Esegui il log out
So many organizations are jumping on the Microservices bandwagon. The amount of hype makes the phenomenon nearly impossible to ignore. According to InfoQ, Microservices and their respective frameworks are in the “Late Majority” stage, meaning that even those industries and enterprises which are slow to adopt new tech are using them. That said, many of those same organizations are struggling to attain the promises that have been espoused by companies like Google or Twitter around Microservices.
If you have started adopting Microservices architectures into your enterprise, you may also feel a bit disappointed in the ROI of the approach. According to many industry experts, Microservices are supposed to promote agile workflows, accelerate delivery speed, improve quality, reduce costs, increase resiliency, and make it easier to hire qualified developers. If my colleagues and peers are any indication, then many of those benefits are not easily achieved.
Let’s focus on agility and speed for the duration of this article. I was recently talking to a friend who works at a company that does advertising on the Internet, and they were early adopters of Microservices architecture (MSA). The intent was that they could have several development teams working on different portions of their business processes in parallel and get to market faster in their fast-paced industry sector. My friend was complaining that MSA was not all that it’s cracked up to be. Several of their teams found themselves bottlenecked when they tried to integrate their services because of a lack of clarity of how those services should interact. When attempting to work in parallel, teams often ended up spending more time resolving integration issues between services. It just wasn’t any faster.
I’ve heard similar stories from my clients, from my friends, at conferences, etc. Some groups started with MSA even though their applications were not a good fit for Microservices. Others started on the path to MSA without considering the prerequisites. Many started adopting even with careful preparation, but are still not achieving the delivery speed that they want. This is because MSA is not something that you can start doing in isolation and instantly achieve benefits. You need to have certain practices and prerequisites in place before MSA can deliver on its promises. That means you likely need to adopt TDD, DevOps, and Agile before you ever consider MSA. Even after those needs are addressed, you still must figure out how to combine disparate teams to work on services that need to integrate well with one another.
One major problem that MSA adopters encounter is that of clear and detailed communication across teams. If the team responsible for the back-end has not completed their tasks, how can the team working on the front-end write and test their code? Similarly, when two or more services need to provide an aggregated functionality, those teams need to have a solid understanding of integrating their applications with one another. Traditional methodologies would have you write a project plan which would then be delivered to those development teams. This requires a lot of up-front time and effort while providing limited benefit due to different interpretations of the plan. It also goes against the desired ideal of fast feedback cycles.
How might we overcome these obstacles? In my experience, an effective method is to practice Contract-First Development. Contract-First Development is a modern practice that functions well the world of web APIs and DevOps delivery methodologies, but shares similarities to older development styles. In traditional C/C++ development, you would write an include file (.h/.hpp) which allows someone working with your library to have a clear understanding of how to call and integrate with your code. By defining this “contract”, you allow the team developing the library to work independently of a team which consumes that library. While this is not a new concept, it needs to be applied in a different manner in the world of Microservices and Functions-as-a-Service (FaaS).
Currently, there are two well used and battle-tested methods of writing specifications for Contract-First Development as it relates to web services, OpenAPI and gRPC. OpenAPI is focused on REST APIs, while gRPC is focused on Remote Procedure Calls.
Here’s an example of how that workflow might look:
- Have the dependent teams, and perhaps an architect and product owner, work together to write a rough draft of the API specification (using OpenAPI or gRPC).
- Use tooling to generate service and client SDK code
- Write tests and implement the services/applications based on the contract
- As development proceeds, missing requirements will be identified and those requirements will lead into refining the API specification iteratively
This is a simple and short cycle that allows progress to be made quickly while iteratively approaching a product that delivers business value. The different teams are not blocked awaiting the work of the others because they can mock or “fake” the dependent service based on the contents of the contract (OpenAPI or gRPC). Since the API specification is very precise, it leaves little or no room for integration mistakes between the disparate teams. Suddenly, many of your bottlenecks between development teams are gone!
Here’s one thing to remember: Your teams will never get this right the first time. This is intended to be an iterative process. Besides, there is no “right” answer. Business requirements change quickly, customer needs evolve, and new features are requested. The API contract should be a living document and the “source of truth” for your development teams. When one team identifies an issue that requires updates to the contract, you manage the document in version control so that everyone is aware and can communicate effectively around the contract. When it’s time for integration and deployment, my experience is that there are few, if any, issues around integrating those services when the contract is followed.
In summary: You can save up-front planning time. You can save integration time. You can improve your organization’s ability to develop services and applications in parallel. You can make quick changes as business needs and customer demands change. Contract-First Development enables all of this. Have your teams give it a try, or have someone come and teach your teams how to do it. I, for one, will never do Microservices Architectures without it again.
Deven Phillips is a Senior Consulting Engineer with Red Hat’s Application Development Center of Excellence. He has more than 25 years of experience in developing software, managing information technology, and mentoring engineers.
Connect with Red Hat Services
Learn more about Red Hat Consulting
Learn more about Red Hat Training
Join the Red Hat Learning Community
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn