About enterprise middle office planning and it architecture microservice transformation

For traditional enterprises IT Architecture transformation , In my previous articles, I have systematically sorted out and elaborated on the architecture planning of the platform and the microservice , Although the concept of cloud primordial is 2013 Put forward in , however 2020 Year can be regarded as the first year of cloud primordial , Simultaneous enterprise IT Architecture transformation , Microservicing and gradual migration to the public cloud will also be a technology development trend in the coming years . Recently combined with partners , Customer communication , Sort out and explain some common problems .

Middle office and micro service planning

In fact, the medium platform planning can be understood as the traditional enterprise architecture and information planning , Tradition SOA A subset of the architecture plan . Its core is still business driven IT, Sort and analyze based on business processes and business objects , Identify core reusable business components and capabilities . Common business capability sinks , Provide coarse-grained interfaces for the upper layer .

Zhongtai itself is a business concept , Not a technical concept .

The emerging consulting companies or software service providers that can do the middle office planning are not very skilled , It is a traditional consulting company or software service provider rooted in a vertical business field . That is, the depth of business understanding of vertical industries , Traditional consulting planning capability , Far more than the technical capacity .

An emerging enterprise goes everywhere to make middle office planning for customers , This is not appropriate , How do you plan for others without settling in the business field , How to identify reusable business capabilities . You have no business accumulation and precipitation , The best methodology can't guide you to practice . Although I have sorted out the methodology of China Taiwan planning in my article , In the same way, I am not familiar with the business field, and I can't actually plan for others .

Familiarity with a technical architecture idea may require 1 weeks , But familiarity with a vertical industry requires at least 1 Years or more . Therefore, it is relatively easy to make technical planning , But it is difficult to do business and middle office planning , The difficulty lies not in methodology , It is business accumulation and precipitation .

Microservices - Don't rigidify Standards

In fact, we are in the process of microservice architecture transformation , There are often two extremes in the process of discussing microservicing with customers . In one case, the big application layer is split , But the database is still a ; Another case is to strictly split the microservices and databases 1 Yes 1.

For the first case, due to DB There is no split , In fact, it is still a tightly coupled system . In the second case, the splitting of microservices leads to a large number of independent fine-grained database instances , This leads to a large number of distributed transaction problems . In fact, it is better to make a compromise according to the situation of the enterprise business domain , Split the database by business sub domain , And the application layer inside the business sub domain , It can also be split into multiple microservices .

Included in the implementation of microservices , It is often said that the front and back ends of your architecture are not separated , Not microservices . In fact, front-end and back-end separation is not a necessary condition for microservices .

For example, some customers are implementing micro services , Although the front and rear ends are separated , But the back end provides API Interface services are all fine-grained , Simultaneous and front-end methods 1 Yes 1, Such front and back-end separation does not reflect the domain capabilities , Key features such as service reusability , Instead, it increases the complexity of front and rear end coordination and joint commissioning , Such separation makes no sense .

DevOps The first is the process , The second is tool integration

about DevOps, Although in my previous article, I also explained in detail our current planning and research and development DevOps Support platform . But everyone has to realize DevOps The first is process improvement and optimization , The second is tool integration and automation .

For example, we have seen some enterprises implement CI/CD Integrate , Process automation, etc , But you will find that from user requirements collection to version planning , To the final development, implementation and launch , The whole process management is still very chaotic , With tools, there is still a need , Research and development , A lot of manual communication and collaboration of testers . that DevOps What is the significance of implementation ？

therefore , about DevOps The first is an agile and continuous integration and delivery process improvement , The second is what kind of tools and techniques to use . Technology is often difficult to reverse the process optimization and improvement , Process improvement requires organization , Team and culture improvement .

From big data platform to data midrange

You can see , At present, many service providers working as data platforms are actually service providers that used to work as big data platforms . So what is the difference between big data platform and data platform ？

For the big data platform, you can understand it as a pure data technology capability platform , The inside itself is empty . Just as we understand ESB The bus is the same , It is a technology platform , At first, there was no interface service registered on it , You need to constantly access new services yourself , To form a service directory system .

For the data midrange, the technology base based on a big data platform is filled with specific data assets , This data asset needs to be layered , Abstract modeling is required , It is necessary to provide external reusable data service capability .

Therefore, the difficulty in the construction of data platforms has never been the big data technology platform , It is the data construction inside , How to model data , How to collect data , How to clean data , How to abstract aggregation, etc . And this also goes back to the key of Zhongtai planning , That is, it requires business capabilities and experience precipitation in the business domain , You can do this .

Simply put, if an enterprise wants to be a data center , Many emerging big data platforms or data mid tier manufacturers may not be reliable , Instead, what traditional vertical fields have been doing for a long time BI The manufacturers who plan and implement the plan are more worthy to entrust .

From cloud native to enterprise cloud migration

I mentioned earlier , For Ali , Public cloud manufacturers such as Huawei and Tencent ,2020 Cloud native solutions , Help traditional enterprises to publicize on the cloud , Although the whole cloud nativity is the general trend of Technology , But the enterprise must realize that from the traditional enterprise IT Architecture migration to the cloud is still a relatively long process .

In particular, the enterprise has an internal private cloud or data center , There are already a lot of leftovers IT In the case of the system , In business continuity assurance , How to ensure smooth migration is extremely difficult .

Each public cloud manufacturer has launched its own migration scheme and plan , Include your own DevOps The R & D integration platform extends into the enterprise , Although ease of use and convenience are increasing , But the strong binding to the enterprise is also increasing . Simply put, you have adopted the solutions and services of a public cloud service provider , In fact, it is relatively difficult for you to get away from it .

secondly , I made a simple comparison some time ago , That is, instead of purchasing virtual machines directly, you can purchase database services directly , It is found that the overall annual cost is relatively high . Sometimes consider purchasing the technical service capabilities of cloud service providers directly , But in fact, many times you still need operation and maintenance engineers , This cost has not been omitted .

At the same time, because of the enterprise IT The system is gradually migrated , Private cloud and public cloud will coexist for a long time , Including some traditional interiors IT The system has performance requirements , Security and other aspects are often not suitable for cloud , These must be considered clearly .

Service governance and control capability

Some enterprises blindly worship new technology , I always hope to adopt the latest technology in the development of new systems , The highest performance technology . But in fact, there are problems in the later management and operation .

The same is true for microservices , The newly developed microservice split , The interface definition did not immediately find problems , However, it was not until the late stage of development or even when it was launched that it was found that the microservices were too finely divided , There are too many interface interactions between microservices . That is to say, after the micro service is split , The microservices are still tightly coupled .

As soon as the system goes online , I found that the entire microservice environment is completely out of my control , It is difficult to solve the problem of operation failure , Logs are difficult to check , A large number of interface changes are dependent, resulting in online failures, etc . These are typical of the whole IT Organizational architecture capability , The service management and control ability can not keep up , It was great to use new technology at the beginning, but it left an uncontrollable mess behind .

China platform and micro service

Is it necessary to adopt the microservice architecture for the construction of the middle office ？

The previous article also talked about , Microservice architecture is the best way to build an idealized midrange . However, the core of Zhongtai is the sinking of common business capabilities and the provision of external services , It can support the rapid construction of upper layer applications .

Then there are a lot of leftovers in the enterprise IT System time , It is not the best way to completely overthrow the original microservice . The better way is to focus on whether the midrange you build provides reusable common business capabilities as the final measurement standard . If it does , The enterprise has built a good middle office . Whether the underlying layer uses microservices is not the key point .

Therefore, although Zhongtai and wechat services are closely integrated , But it doesn't really matter .

Microservices may not be used for the construction of the midrange , Traditional architecture can be adopted , It can also be done through the legacy IT System interface adaptation . For microservices, it does not necessarily reflect the characteristics of the middle office , The core of microservices still lies in the splitting of traditional large monomers , The reusability of the split interface service is a sufficient condition rather than a necessary condition .

Don't deify the low code development platform

Return to the next 2020 Years of technological development , It is found that low code development platform is a hot spot in a hot spot , There are a large number of low code development platform manufacturers and cloud service providers . Some are traditional BPM Manufacturers of class , There are also some manufacturers that are themselves fast development platforms , Of course, there are some platforms that completely provide zero code assembly .

No silver bullet has been said for so many years , There will be no big change in the short term .

So where is the embarrassment of the low code platform itself ？

For SMEs , What is needed is not low code development , It's direct SaaS service , about SaaS Service products can provide some flexible processes , jurisdiction , The configuration capability of data items is sufficient . For large enterprises , Many business processes and business scenarios , Especially complex business rules , Low code platforms do not solve . Even if the solution is solved, there is still a lot of complex script code .

The low code platform assumes that every object , Each function is relatively independent , But in fact, for complex business, objects are related , There is collaboration and integration between functions , Business logic is difficult to configure . These are not problems that low code platforms can solve .

If you really want to be a low code development platform , You will see that the only good direction is the vertical business industry + Business system . The more vertical , The easier it is to abstract things that can be reused to provide . In other words, it actually provides a vertical industry + The capability of a business platform under vertical business , This is the most valuable . Finally, the little friends who love learning can study java Level digital new retail saas product weiit-saas, This is already completely open source ！