The Future of Microservices

To understand the current and future state of microservices, we spoke to 25 IT executives from 21 organizations. Consistent with the early adoption of the technology, the answers to our questions were diverse. We asked them, "What's the future of microservices?" Here's what they told us:

FaaS/Serverless

• 1) Maturation of the way the software development can effectively use the pattern. Establishing best practices. Things start to change and evolve as more developers get involved with microservices and apply their skills and experience It will take a while for the maturation process to soak in. 2) Continued decomposition of software to the function level is very early. There is no body of best practices. Some microservices will apply at the function level and some will not. FaaS being used as glue, the scripting language of the distributed environment. Not the end state for FaaS just a place that’s showing the most value right now. We will see the emergence of best practices with staying power. FaaS is a few years behind microservices. The use of the capability will accelerate as glue and be the foundation for how we build business apps in five to 10 years. 
• Improve way to develop Kubernetes (K8s) and tools provided by AWS and GCS help go from development to deployment and production more quickly and easily. There is a big difference in orchestration and managed services. More teams and services are exploring what’s beyond REST-like GraphQL integrated into services. Serverless approaches, frameworks, and platforms will be more important as will hybrid solutions with APIs. 
• Serverless is gaining traction. Frameworks, functions, serverless, moving so fast it's difficult to pick the right tool. 
• The biggest opportunity for success lies in continuing down the path with containers and serverless where infrastructure is less of a barrier to entry. We're getting close to the point where a developer can create a service and deploy without caring where it resides. Deployable containers where you don’t have to provision VM with things like Hyper.sh, Azure Container Instances, and Amazon Elastic Beanstalk. 
• In the near-term, we will see an increase in the composition of application. Then we'll go smaller with FaaS and serverless. Microservices become even more "micro" into some form of serverless. We see adoption increasing. The gap in standardized definitions and patterns will improve and increase with increased adoption and will drive increased adoption. Commercial and open source will offer more tools to manage the complexity includes managing deployment across service, testing, and development. We currently see a lot of confusion around data and databases. We’ll start to see an evolution around databases and data. 
• We’ll continue to go down the path see how hard it is and not get the value they expected and then abandon and go to serverless. Seeing that with SOA right now. See the hype of serverless and it will be distracting. Serverless and FaaS are different but are the next evolution of application development. There’s a lot of value in going to a serverless model. It’s a business decision about where and how you look at building new products. There’s a lot of uncertainty when building a new product. If you look at your capacity to build an application and try a bunch of different things a lot of which will fail. From that perspective, it makes a lot of sense to not try to own as much technology and infrastructure as possible. I don’t care where services run but I need to connect them. I need a way to build an app quickly and stitch these preexisting services together. That’s the serverless model. Use functions to stitch together, then figure out how to scale. Then it may make sense to own some of those capabilities you were outsourcing. Don’t give up owning the SLA, price, and feature roadmap. There are great use cases for serverless. Coexisting ecosystems. Depending on where you are in the lifecycle of the product and business decisions you need to have flexibility. 
• I think that a lot of microservice practices make sense at least for bigger systems or companies. But we still have a lot to learn and many best practices to distill. But as we improve there, I think microservice paradigms offer a great help to survive the ever-increasing complexity of most systems. Personally, I also think serverless will be huge in the future. That is somehow connected to microservices as e.g. with Functions as a Services you break down your application into even smaller pieces, which then need to be coordinated to fulfill a useful overall business capability. So microservices are an important step on the learning journey that also might lead us closer to serverless. And the promise for the software developer of finally getting rid of operational details is great — and the promise of huge costs savings by only paying for the exact amount of compute used is even more appealing.

Tools

• The whole movement to microservices allows you to create a vibrant marketplace. Since decomposed apps are moving to microservices which I can consume from cloud providers, there's a big public marketplace with specific functionality.
• Better tooling to run microservices. If you just look at the monoliths they’ve evolved over 40 years. They’re convenient and have good instrumentation. People looking for the tools that provide vision and orchestration how to run the company infrastructure using microservices. I would hope an ERP would do this. Need access to real-time data. Hybrid cloud some run microservices in one cloud but not another. Don’t like lock-in.
• Simplifying as much as possible so developers, operations, and DevOps can run the apps they want and it scales automatically as needed. Have everything at your fingertips to troubleshoot any problems without worrying about the underlying infrastructure and orchestration. Hide Docker and K8s to allow developers and operations to focus on what matters to them. Tighter integration between integrated development environments, source code repositories (GitHub), with the deployment environment. All three become more integrated for developers and operators.
• Tools, Java has acknowledged the footprint is important. JDK 9 has been modularized. You can have a much smaller footprint. It's important for Java in the context of microservices.
• Microservices are not a panacea, and enterprises will learn that successful adoption requires the same rigor as traditional development. Tools to assist in the microservices lifecycle will be required to help develop, test, secure, deploy, monitor, orchestrate, and consume these services, providing an opportunity to innovate in these areas.

Other

• As more, higher level frameworks gain adoption more microservices will be used. A lot of people think they are doing it, but they are not. If you are constantly incurring infrastructure pain for no good reason up-leveling has to occur.
• Security perspective – microservices are more insecure than monolithic apps because of their context and disposable nature. Going forward, as we start writing microservices-first code, we need to start adopting a tighter governance level with secure design patterns as the basis for all ongoing development. Like the Netflix chaos monkey, there will be newer techniques adopted within DevOps to assure security quality of microservices applications.
• It's why we introduced a service architecture. Containers are successful. K8s are filling the blanks of the container world. That part of the technology is improving day by day. Everything will become a microservice, being fully stateless, immutable, and dynamically scale with containers.
• Very bright for anyone building powerful software at scale with a lot of developers. You don’t have hundreds of developers working on one piece of software. Something structurally like microservices will work in the future. It’s about communication and the principals of engineering management.
• There are many pieces. You don’t have to create ID verification if there’s already a service out there. You don’t have to spend cycle time developing. When predicting if someone will repay a loan, ID verification is needed but it’s not a key variable in the decision. Focus on the discrete service you are developing and turn to other services to provide other functions. It will end up like open source if someone creates an infrastructure to share services.
• The greatest opportunities are around stateful microservices since most enterprise critical applications maintain state.
• For every company, the specific answer is different based on what their business objectives are. For us, running quickly, using canaries and other deployment strategies has been a highlight. We have 5-6 “macro” services and we can iterate on them individually without affecting the nearby services. Services have helped increase the frequency of our deployments.

Here’s who we spoke to:

from DZone.com Feed https://ift.tt/2Dekxx5