• The operating system used to deploy your applications
• The availability of the libraries your application used

One extreme example of how the operating system influences this decision is when CentOS is used. CentOS is really close to Red Hat Enterprise Linux (RHEL) minus the commercial support, and many companies that started off with RHEL and grew internal teams, ended up moving to CentOS. There are a lot of good reasons to use CentOS. This Linux distribution is popular and based on a robust set of management tools.

However, using CentOS means you cannot use the latest Python version for your projects unless you install a custom Python instance on the system. Moreover, that is often considered to be bad practice from an Ops point of view because you go out of the supported versions. For that reason, some developers were forced to use 2.6 for a very long time, and that prevented them from using the newest Python syntax and features.

The other reason people stayed on Python 2 was that a few essential libraries were still not ported to Python 3. However, this is not the case anymore--if you start a new microservice project in 2017, everything is available for Python 3.

Those two reasons to stick with older Python versions are gone nowadays; you can pick the latest Python 3, and ship your app on whatever Linux distribution is inside a Docker container.

As we've seen in Chapter 10, Containerized services, Docker seems to be the new standard for containerizing applications. But, maybe, other players will become serious alternatives, like CoreOs's rkt (https://coreos.com/rkt/). In any case, the maturity of the containers technology will be reached the day all containers engines are based on a universal standard to describe images--and that is the goal of organizations such as Open Container Initiative (OCI) (https://www.opencontainers.org/), which is driven by all the big containers and cloud players.

For all these reasons, using the latest Python 3 and Docker for your microservices is a safe bet. Your Dockerfile syntax is probably going to be very close to whatever syntax an initiative like OCI will build.

So, if Python 3.6 or the next versions have great features, nothing will prevent you from moving forward and using them for your next microservice--and as we've said throughout the book, it's fine to use different stacks or Python versions for each microservice.

In this book, Flask was picked, because that framework is excellent to build microservices, and has a vast and mature ecosystem. But since Python 3.5, web frameworks based on the asyncio library (https://docs.python.org/3/library/asyncio.html) along with the async and await new language keywords are starting to become serious alternatives.

There are good chances that in a couple of years, one of them will replace Flask as the most popular framework, because the benefits regarding the performances of I/O bound microservices are huge, and developers are starting to adopt asynchronous programming.

In this last chapter, we are going to look at how asynchronous programming works in Python 3.5+, and discover two web frameworks that can be used to build microservices asynchronously.