I went there because Microsoft Terada-san's one-man session was held by Seki Java. A session on the same theme has already been held at JavaOne Tokyo, etc. and has become a hot topic, but it was very helpful as it was well received.
Kansai Java Engineers Association [Osaka] 7/12 --Cloud Native Date: 2017/07/12 (Wednesday) 19: 00-21: 00 Location: Microsoft Japan Kansai Branch
For cloud-native scalable app development 12 Factor App on Kubernetes on Azure
--JavaOne Tokyo 2017 Material: Microservices Development for Java EE Developers Now --de: code 2017 document: For cloud-native scalable app development ~ 12 Factor App on Kubernetes on Azure
⇒Since we have time this time, we proceeded with Seki Java Original Ver. Based on these.
https://yoshio3.com/2017/07/05/2017-java-appserver-usage-questionnaire/
Java server usage 1st place: Tomcat
If you have already migrated to the embedded container (executable jar), which framework did you migrate to? 1st place: Spring Boot
Details will be written on the blog at a later date
(* People who are already making microservices in development projects ... about 5 people)
⇒I don't know where to start ⇒It is actually difficult to introduce even if the theme is the latest trends Today's theme ⇒ How to approach microservices
Move what was working on-premise to the cloud as it is ⇒I can't get the benefits of the cloud
(* People who answered that it is necessary ... about half?)
Knowledge and know-how are required as an engineer ⇒Everything is not a microservice ⇒ It is not a choice between monolithic or microservices
――If you proceed without thinking about microservices, it will go bankrupt. -Make microservices happy, not make them happy ――The effect cannot be obtained unless you think about and realize a method specialized for your service. --If you don't think about it, you will fail. We need to think more than ever.
◎ The worst pattern
--MSA for the time being --I want to make it Docker
◎ You can do it without MSA
--Providing services as soon as possible --Flexible scale --Creating an independent service
◎ MSA effective pattern
--Fault tolerance --A system that is resistant to changes (* This is the greatest merit)
--Introduced ... 15% --Migrate existing services ... 25.4% --Introduced as a new service ... 35.8% --No plans ... 23.9%
Especially in the United States, there is a sense of crisis that we do not know when our business will be destroyed. Rakuten and others have the same tendency in Japan
――It is important to build a good team --Documents are useless --Team power is important --Mobupro ... You can't do it without a good team
The twelve-factor app
https://12factor.net/ja/
(* Kubernetes people who have touched ⇒ 2 or 3 people)
DEIS… Workflow engine http://deis.io/ http://qiita.com/wataru420/items/4bc7c52313d5d06a847c
Hands-on https://github.com/yoshioterada/DEIS-k8s-ACS
[Conventional] Manage multiple services with one repository [MSA] Separate repositories for each service ⇒ Easy to understand service change history
--Separate view and logic --The front end can be anything --Backend handles RESTful Web Service and JSON --Make stateless --Split UI and backend service
[Conventional] Realized using the function of the application server [MSA] Stop relying on application servers ⇒ Go out session information
Inmemory Grid
Application server session management cannot scale as session information grows
Asynchronous ← Those who are going to learn MSA must study
Is it synchronous? Is it asynchronous? ⇒ Think about synchronous or asynchronous instead of alternatives
Blocking / non-blocking is also important ⇒ When blocking, specific services accumulate due to parallel processing
Detach and recover a specific service in the event of a delay or failure
(* People who handle shared libraries ... 60%?)
--Separate shared libraries --Share for each service instead of sharing for the entire service
Build ⇒ Set up a private repository
-Sonatype… 30%? -JFrog Artifactory… 30%?
--Make it work in any environment --External environment settings ⇒ DB connection settings etc. in properties
Environment variable or setting server ⇒ Read the settings from the environment variables
Build / release using DEIS Allows quick rollback
Become a self-contained and lightweight app Publish services through port binding
--Unify development and production environment --From hot deploy to continuous deploy --Let's stop at night or on weekends --Test in production, switch and release
Realization method
Java Feature Flag… toggz
It's hard to see the raw log Try to spit out all Zavis logs Check with elasticsearch etc.
1.1 Service 1 Database (RDMBS on 1VM) 2.1 Service 1 database (RDMBS on multi-VM) 3. Database linkage (message linkage) --Use a messaging system 4. CQRS (Read-Write separation) --For example, read only scale
Where complete transaction management is required, message linkage does not have to be ⇒ Think about the appropriate method
Obstacles occur ↓ [Conventional] I will do my best not to get up [MSA] Make it safe to wake up
Where does the failure occur? ⇒ Wake up in all
Release It! For designing and deploying production software products
Looking directly at the reality that microservices are not good or bad, but the only way to realize them is to think carefully about the way that suits them, and give hints on how to think about how to find a better form of service. I think it was the content that was presented. You mentioned at the beginning that a lot of new technologies are coming out and there are a lot of things to study, but I think that's true. Benkyo! Benkyo!
Recommended Posts