I have done a lot of service development for what would be called microservices. The article gets it right in ny opinion. 1. It has a lot to do with organisat

I have done a lot of service development for what would be called microservices. The article gets it right in ny opinion. 1. It has a lot to do with organisational constraints. 2. It has a lot to do with service boundaries. If services are chatty they should be coupled. 3. What a service does must be specified in regards to which data it takes in and what data it outputs. This data can and should be events. 4. Services should rely and work together based on messaging in terms of queues, topics, streams etc. 5. Services are often data enrichment services where one service enrich some data based on an event/data. 6. You never test more than one service at a time. 7. Services should not share code which is vibrant or short lived in terms of being updated frequently. 8. Conquer and divide. Start by developing a small monolith for what you expect could be multiple service. Then divide the code. And divide it so each coming service own its own implementation as per not sharing code between them. 9. IaaS is important. You should be able to push deploy and a service is setup with all of its infrastructure dependencies. 10. Domain boundaries are important. Structure teams around them based in a certain capability. E.g. Customers, Bookings, Invoicing. Each team owns a capability and its underlying services. 11. Make it possible for other teams to read all your data. They might need it for something they are solving. 12. Don't use kubernetes or any other orchestra unless you can't it what you want with cloud provider paas. Kubernetes is a beast and will put you to the test. 13. Services will not solve your problems if you do not understand how things communicate, fail and recovers. 14. Everything is eventually consistent. The mindset around that will take time to cope with. A lot more...