I have several microservices cooperating with each other which I'd like to deploy independently. What are the prerequisits for such scenario? Or better: what are the best practices?
What I came with so far is:
contract versioning
atomated intergration tests
phased (canary?) deployment scenario to minimize risk
rollback scenario
Are there any others topics to consider?
Related
For our new SOA, we are looking at Kafka as a message broker.
I wish to ask, what are our options to organize workflows in messaging?
It looks like there should be a coordinator/supervisor service which concentrates knowledge about an order, in which messages should be published and processed. And probably writing it from scratch is not a good idea.
I seen a few workflow engines, but not one which is designed specifically for use with Kafka, or advised to be used with it. I'm afraid that looking at Kafka, we've chosen the wrong tool, because building complex and reliable workflows is a must from our perspectives.
Any advice please: workflow engine? Another messaging platform? Go to work in McDonalds?:)
Are there any differences in CI/CD approach when we talk about Big Data applications in Hadoop or Spark and traditional applications?
I believe it depends how you will update your services.
If you can use blue/green or rolling deployment strategies you should have no problems updating your servers and will be able to keep your data flowing.
Is SOA solution by making a centralized service which works as a central backbone service for all other services is a good approach?
Its doable, but you need to consider service granularity.
Incorrect granularity could mean that a service covers too much functionality or too little functionality.
Incorrect granularity of services in your SOA can lead to bad performance, low reuse possibilities, leaky abstractions and services without added business value.
Other problems:
You're not able to explain to business people (e.g. sales/marketing) what the service does. It simply does not fit in their understanding of the business the company is in. The services are at a level of detail that is irrelevant from a business perspective.
Many different services are needed to achieve something of value to the business.
There is no clear ownership of the service, multiple department feel they should own the service (or parts of it).
We have built an enterprise web application on asp.net platform which is well load balanced across several servers. We are struggling a bit in terms of doing regular deployments as the application has been defined with an SLA of zero downtime.
Any guidance / tips would be highly appreciated for Implementing best practices to support uninterrupted deployment.
My two favorite books that cover some of these topics are Continuous Delivery by Humble/Farley and Web Operations by Allspaw/Robbins.
I think the "easy" part here is to do a rolling deployment where you pull a node out of the load balancer, upgrade it, run smoke tests, and place it back in the load balancer. Different users will encounter different versions of the app, but you get zero downtime.
The hard part is the backend system / database that these web-apps are likely hitting. You basically need to have both old and new schemas available concurrently which is challenging. Look at techniques like the expand / contract database pattern as an approach to pulling this off.
I look after the merging, deployment and release of Products & Services in the Company I work for. I've slowly moved to this position from development so a lot of this is new to me (I guess!)
We have a deployment process, but no real Release procedure other than telling stakeholders and members of staff about these new services/features/bug fixes shortly before release.
I've heard things about ITIL Release Management, CMDB, versioning and other mumbo jumbo, but are they actually needed or am I going to end up being weighted down in by a load of crap.
The question I guess I'm trying to ask is: what's my first step? Am I making a mountain out of a molehill? How do I shape this department?
Steve
In my opinion following ITIL practices or implementing a CMDB are not necessary but best practices. The most important thing, and first step, in your case, is developing or documented sound processes about what you do. For documentation you can use "programmer friendly" tools like a wiki (MediaWiki, TikiWiki), but if you do not document your practices it is very difficult to implement continual improvement.
If you have already implemented and documented your processes you can study standards and best practices related to your department. ITIL and ISO 20000-1 are standards focused on the quality of services you offer. Services, not ongoing operations. ITIL can provide you with some useful (but not necessary) good practices like implementing a CDMB. If you implement a CMDB correctly your department will have in a database the configuration of the assets you use to provide your services. You will be able to store the configuration of the systems on your clients or what you want. The CMDB can associate its elements with incidents or known errors so the support department could provide the best service to your clients.
CMMI or CRUM are other standards/frameworks that will probably interest you.
About versioning, I think some sort of versioning is a must. GIT or Subversion are good options.
Other tools very interesting in my opinion is some kind of continuous integration, like Jenkins and some ticketing system like Trac or Mantis.