Shifting from the monolith to the cloud with microservices

Rapid application deployment is vital for companies to meet consumer demands, compete in the market and scale for the future. Quickly delivering software to support your organization across these facets is a tall order.
Developers often spend their days building something new or debugging something that’s broken, which is why they want a solution that simplifies the development process, making it faster and easier. The faster they can improve existing apps or find errors in the code, the more time they have to learn new skills.
The benefits of microservices — agility, shorter development time, flexibility — help developers build something more robust faster and with fewer problems. The challenge some developers face, though, whether due to the culture or ingrained processes within an organization, is making the shift to building in a microservices architecture.
For developers advocating for the adoption of microservices, a few things can make the shift smoother: learning microservices development best practices, optimizing which languages to use, using an opinionated stack and preconfigured pipeline, and testing apps using continuous deployment.
A major mental shift
When shifting to microservices, there are best practices developers must adopt. It’s important to understand that building microservices isn’t merely breaking things into pieces. It’s also about automation and the method for developing software.
Take continuous deployment, for example. When building a monolithic application, you must build all of the pieces together. However, if you need to make updates or perform maintenance, the entire application must be rebuilt and deployed. This downtime could negatively affect the user experience and create more fire drills for your team because you’re scrambling to make the changes as fast as possible.
Microservices eliminate this, because each microservice is a small piece of an application. To make an update, you may only need to look at one or two microservices, making it easier to implement changes. Take advantage of this capability and practice continuous deployment to refine the app faster.
Choose the best programming language
Unlike a monolith in which everything must be written in the same language, microservices provide the freedom to choose the programming language best suited for an app.
For example, Microclimate, an end-to-end, cloud-native platform, currently supports Java, Node.js, Swift or bring-your-own template. Developers build microservices using Docker containers. This flexibility means you can have a team or a single person working on one piece of an application using Java, and another team can work on a different piece coding with Node. The various parts of the application still function cohesively, and you can build higher-quality apps.
Speed ahead with an opinionated stack
An opinionated stack provides a predefined framework or code base that’s built using specific design patterns that follow best practices.
This capability simplifies specific development tasks because it provides a predesigned path. Developers don’t need to make as many decisions and spend time on setting up, leaving them with more time to focus on app optimization.
Move into production faster with a preconfigured pipeline
Many tools used to push an app into production require setup first, adding a step to the process. A preconfigured pipeline, such as Jenkins, abstracts this extra step, helping save time and effort and push the code into the environment faster, simplifying build and deployment.
This agile approach, combined with a microservices architecture focused on one piece of a broader application, lends itself well to continuous integration and deployment. The faster companies get an app into production, the faster developers can receive feedback to improve it.
Release and test one thing, not the whole thing
Testing a monolithic app is complicated because test environments must be created to simulate what an application might do when live. This extra step makes implementing changes slower and more challenging. Also, there is a greater risk of downtime in a monolithic architecture because developers have to rerelease the entire application. A bug in one module could impact the availability of the entire app.
The beauty of microservices is that developers can test one part of the application in a live environment without affecting the entire app. They can also choose different testing methods such as A/B, red/green, canary or geolocation testing.
For example, if developers are doing geolocation testing, they can release live code for a new feature in Canada. If it runs smoothly, they can then release it globally. While the new version is running in Canada, the old version of the same app is still running everywhere else. This dual deployment lowers the risk of widespread downtime if something goes wrong.
It’s about what’s best for your needs
While microservices provide compelling evidence for adoption, there are some cases where it makes sense to integrate microservices with a monolith. Ultimately, the choice should be made based on what’s best for your organization.
If you choose to adopt a microservices architecture, remember you don’t need to do it all at once. An excellent way to get started is to evaluate your monolith, find a service that can be  built as a microservice, build the microservice and redirect traffic to the new service, then seek out a next service. This approach, along with an integrated end-to-end development platform such as Microclimate, can smooth the transition from monolith to microservices.
Learn more and get started with Microclimate.
The post Shifting from the monolith to the cloud with microservices appeared first on Cloud computing news.
Quelle: Thoughts on Cloud