1) This is a cultural change in organisationTrue. Microservices are like a mental change how we do software. There are going to be many, smaller projects, a layer of network communication, releasing and versioning issues. If you have a team of people who never wrote any automation scripts, never released their own projects in production environments, never did any CI/CD - it will be really hard. You can expect a lot of resistance, learning curves will vary depending on personal ops experiences, collaboration in team and willingness to learn new, different approach.
2) Microservices are easier to developYes and no. It is easier to develop such services on its own - projects are smaller, it is easier to jump and get the understanding of business logic inside a single project, fix a bug, upgrade libraries. On the other hand - you need a well functioning deployment pipelines and good inter-services communication patterns to get all the things going. The power of microservices is because they operate together - but this is also a big challenge itself, as networks can fail, messages can be dropped, responses could be randomly timing out, testing is different and may feel harder, teams may not communicate well and so on. You need to decide on communication (sync/async), develop patterns for graceful failing, handling errors, startup/initialisation and so on.
3) You need devops cultureYes, true. For a working solution, every development team should be able to test and deploy. Deployments should be simple and easy to repeat. Think about one-click deployment pipelines. Teams should be cross-functional. Operational excellence and understanding of devops and continuous integration principles comes also from understanding production environments. Monitoring, metrics, logging, tracing requests, dumping messages. Troubleshooting issues at 3am, reverting to previous versions, fixing corrupted data, all these things helps you to develop culture of operational excellence. "Bad behavior arises when you abstract people away from the consequences of their actions"
4) You need to have a good TDD/BDDNot per se, but it helps a lot. Technically you don't need to have automated tests to prove your software works, but you know it helps a lot to move faster, make important changes safer and it is usually cheaper when you can quickly prove new version doesn't break existing functionality.
5) You need continuous deliveryA simple, working solution to push new changes easily helps a lot. Actually it is more like a cause-and-effect loop - a microservice project is small so it is faster to change it and deploy more frequently than a big, monolithic app. It has to be easy and every developer should be able to release changes.
6) You should (not) use RESTIt depends. Communication patterns like Rest tends to be simple and well-known to start with, but with more complex environments, they can be terrible in terms of error-handling, decoupling and fail-over. With synchronous patterns like rest, one service depends on current availability of another, even if the job flow doesn't really require it. That makes e.g. failing gracefully with partial outage much harder. Async communication on the other hand has higher initial cost, it could be also harder to follow such execution paths in the code.
7) You need to use containers like dockerWhat you really need is to have manageable, versioned, repetitive environments where you can easily deploy your services. You can archive it in many ways - good orchestration tools like ansible/salt/chef/puppet or whatever is hot and tasty today.
While technically it is possible to build images/machines every time, caching some pre-build stages as e.g. docker images and adding only your changed service may speed up this process a lot.
You need a quick release cycle, so if docker helps you to archive it - go for it.