<p>Firstly, I apologize for the rather basic question. I am just beginning to learn about Microservices Architecture and would like to get my basics right.</p>
<p>I was wondering if topics such as AWS cloud services/web services imply the Microservices architecture. For instance, if someone is working on an AWS project does that mean that he is using a microservice architecture? I do understand AWS, Docker etc is more of a platform. Are they exclusively for Microservices?</p>
<p>I would really appreciate a short clarification</p>

user92720
<p>Microservices, cloud infrastructure like Amazon Web Services, and container infrastructure like Docker are three separate things; you can use any of these independently of the others.</p>
<p>&quot;Microservices&quot; refers to a style of building a large application out of independently-deployable parts that communicate over the network.  A well-designed microservice architecture shouldn't depend on sharing files between components, and could reasonably run distributed across several systems.  Individual services could run on bare-metal hosts and outside containers.  This is often in contrast to a &quot;monolithic&quot; application, a single large deployable where all parts have to be deployed together, but where components can communicate with ordinary function calls.</p>
<p>Docker provides a way of packaging and running applications that are isolated from their host system.  If you have an application that depends on a specific version of Python with specific C library dependencies, those can be bundled into a Docker image, and you can just run it without needing to separately install them on the host.</p>
<p>Public-cloud services like AWS fundamentally let you rent someone else's computer by the hour.  An AWS Elastic Compute Cloud (EC2) instance literally is just a computer that you can ssh into and run things.  AWS, like most other public-cloud providers offers a couple of tiers of services on top of this; a cloud-specific networking and security layer, various pre-packaged open-source tools as services (you can rent a MySQL or PostgreSQL database by the hour using AWS RDS, for example), and then various proprietary cloud-specific offerings (Amazon's DynamoDB database, analytics and machine-learning services).  This usually gives you &quot;somewhere to run it&quot; more than any particular design features, unless you're opting to use a cloud's proprietary offerings.</p>
<p>Now, these things can go together neatly:</p>
<ol>
<li>You design your application to run as microservices; you build and unit-test them locally, without any cloud or container infrastructure.</li>
<li>You package each microservice to run in a Docker container, and do local integration testing using Docker Compose, without any cloud infrastructure.</li>
<li>You further set up your combined application to deploy in Kubernetes, using Docker Desktop or Minikube to test it locally, again without any cloud infrastructure.</li>
<li>You get a public-cloud Kubernetes cluster (AWS EKS, Google GKE, Azure AKS, ...) and deploy the same application there, using the cloud's DNS and load balancing capabilities.</li>
</ol>
<p>Again, all of these steps are basically independent of each other.  You could deploy a monolithic application in containers; you could deploy microservices directly on cloud compute instances; you could run containers in an on-premises environment or directly on cloud instances, instead of using a container orchestrator.</p>
