Let’s admit it – web services (SOAP) are here to stay for a few more years, and maybe for a long time in some places where there is no business incentive to rebuild them. However, with a decline in new SOAP web services and most applications moving to cloud native architectures, a common query is “how can we support legacy services while moving to microservices?”
In the first post of this series, we looked at the state of your organization, how to tell if Microservices are right for you, and wrapped up with a few challenges this architecture brings to the table. In this article, we will look at organizational changes that will help you adopt a Microservice architecture. Additionally, we will touch on topics like how to bring change to your organization, how to embrace the primacy effect, and why you should embrace cross-functional teams.
A lot of enterprises are evolving their monolithic applications into microservices architectures. In this pattern, applications are composed of fine-grained services that communicate via APIs. Microservices promise, faster development, innovation, cloud scaling, better infrastructure optimization—and happier developers. No wonder this architecture gets so much attention.
In the current microservices DevOps environment, there are tough new and evolving challenges for developers and teams to consider on top of the more traditional ones. From worsening versions of already common threats to new-generation evolving threats, new perspectives are required on securing microservices. These new perspectives may not be intuitive for many otherwise sophisticated DevOps and data teams.
As we continue to expand across new industries and regions, we’re excited to share Cargill’s digital transformation story and how it turned to Kong Enterprise to create a unified API platform across existing legacy and newer cloud native systems. We talked to Jason Walker, senior enterprise architect at Cargill, about their journey to microservices. What was the driver for Cargill’s move to microservices?
