cool hit counter Five ideas for adopting microservices and container architecture_Intefrankly

Five ideas for adopting microservices and container architecture


As the lead Site Reliability Engineer (SRE) for the New Relic Container Fabric project (our in-house container orchestration and runtime platform), I spend a lot of time with existing and potential customers answering questions about how we use and manage containers to create platforms consisting of dozens of microservices.

We definitely consider ourselves early adopters of containers, and we started packaging services in containers almost as soon as we released our first production-ready version of containers in the summer of 2014. Many of the clients I've spoken with have just started - or are considering starting - a trip like this, and they want to know everything we know. They want to know how we make it work, and how we structure it. But, I want to emphasize that they need to know what we have learned from what we have gone through in this process.

With that in mind, here are 5 key points I'd like to share with anyone considering containers and microservices:

1. Development never stops

Take your adoption project seriously and treat it like a product. Give it a name, even some internal branding, a clear vision of the product. It should be managed and given life.

Our current version of the container structure isn't our first attempt at custom orchestration and delivery. We built our original version in 2014, and once we reached the point where we thought we needed it, we stopped development. We don't have a full vision of the deployment platform developers like to use and build, it only meets our needs for a consistent abstraction layer.

So two years have passed before we started to reinvest in our container platform. Our first release didn't stop working, but we didn't capture many of the incremental improvements that came out of Docker's rapid development phase.

One of our longest running customers went through a similar container orchestration/microservices process during the same time period and they were much further along than we are today. When we asked them how they got to this point, their answer was simple:- "We just keep trying."

2. Build it step by step and start with early adopters

When you move to containers, adopting a new technology (like Kubernetes) doesn't mean you go straight into the deep end and move your entire production fleet into a huge obtainable cluster. Wouldn't it be easier to make things piece by piece?

When we started using Container Fabric, we limited rollout to the simplest use case where we could serve stateless HTTP services - no persistence, no non-HTTP protocols, and only one deployment option. This reduces the feature footprint of the platform to the point where we know we can serve it effectively within a reasonable timeframe.

This is important because container scheduling platforms can't provide everything. We still need to monitor the platform, deploy changes to it, handle secrets, configure automatic load balancing, and capture logs - all of which come with a rich services platform. Restricting the target service type makes it easier to infer the components of the platform.

So if you determine that you need some kind of container orchestration, take a closer look at what the container platform offers and consider what is missing. What do you need to build on top of that platform to support your specific services and infrastructure context?

In addition, get to know the culture and availability of the team. Who are the early adopters of your company? Which teams are ready to enter a new paradigm? Which teams are building services that fit into the microservices architecture? Which teams are stuck with huge legacy monolithic applications that require more time, planning and experimentation?

3. One model size does not fit all

When it comes to containers and microservices, some systems don't fit this model and it's easier if you recognize this from the beginning. The technology in the new system is usually such that the effort to port the old system can be more trouble than it's worth.

Our platform continues to primarily serve HTTP services, but we are also starting to handle more stream processing services. We still don't do persistent storage or databases. (The database team uses Megabase to handle this. )

The latest technologies and architectures are all about rapid iteration and decentralized control, so if these things aren't important to your business goals, then let these old legacy systems slowly retire until you have a logical business need to migrate them.

4. Technological change is organizational change

When New Relic teams move their services to Container Fabric, their operational workload is typically reduced. In some cases, the team will work a lot less, allowing them to get more bang for their buck on other projects. This is a prime example of automation easing the workload, and we're glad to see it. Migrated teams have more freedom to build software that satisfies customers

Organizations considering migrating to a container and microservice architecture should ask themselves the following questions:

What product does your operations group offer to developers and what abstraction layer does that product use?

Is this the right fit for your business or is the container more appropriate?

Are the containers so much better that you are willing to change the abstraction and thus the entire product offered by your operations team in order to use them?

Are you ready to create new roles to manage the scale and reliability of this new abstraction?

No organization has changed overnight like this. The process of moving from an ideal new architecture to a first production deployment requires changing many minds and creating new processes - which isn't always fun.

5. Developing software requires human experience

A rich, complex container scheduling platform requires hundreds of years of experience to build, maintain, and scale. These platforms and architectures require you to embrace new contexts and require your organization to accept trade-offs in your design so that you can adapt it to your use cases. Adopting a containerized microservices architecture is an important exercise that can change the balance of work for all your teams; It affects their way of life; It can sometimes affect their happiness at work. Unless you really consider these human aspects of platform adoption, migration will be much more difficult than it needs to be.

Thanks to our organizational structure, we are well positioned for a successful migration. Each service in the new Relic is owned by a team that plans, schedules, deploys and operates it. This structure has been in place for years, and the Container Fabric platform makes the job of these full-owner teams easier, allowing them to elevate the operational abstraction layer and get closer to business goals.

The promise of containers, and especially their scheduler platform, is often "this is how everyone should develop software - it's full of magic". This is usually true as the container platform does make for some very powerful features and deserves to be taken seriously. But remember, they both address platform productization in a stubbornly stubborn way. If these views can also be your own, then you need to rationalize them.


Recommended>>
1、express project creation steps
2、SEO Miscellany 2
3、Java development GUI of graphics drawing primary
4、Google 10 Tips for Great Mobile Site Design
5、Linux installation of OpenRestyapi gateway Orange

    已推荐到看一看 和朋友分享想法
    最多200字,当前共 发送

    已发送

    朋友将在看一看看到

    确定
    分享你的想法...
    取消

    分享想法到看一看

    确定
    最多200字,当前共

    发送中

    网络异常,请稍后重试

    微信扫一扫
    关注该公众号