1

Although things have come a long way in recent times, in my workplace we're still talking about DLLs, containers, configs, substitutions, pipelines - all complexities when it comes to shipping code.

We deploy many of our .NET applications like so:

  • Containerise everything with Docker
  • Build everything and run all tests in TeamCity
  • Push everything up to AWS

The approach we take still says "we'll manage absolutely everything on our side in terms of packaging our app, how it will run, and then give the cloud platform the pieced together result to handle the actual running".

The way I see the future, why can't we simply log into AWS/Azure, write all our application code in some provided IDE (maybe also give some high level infrastructure config), and then let the Cloud Platform take care of the rest?

If they have our source code, what else do they really need? They can run our tests, package the app, and deploy it given some basic config (#instances, networking restrictions etc). Why do we need to think about anything else other than the code and set up pipelines, config replacements, container configurations etc?

Obviously Lambdas and serverless are an approach to this, but they've strangely jumped many steps which puts limitations on the structure of functions and state etc. Can we not just write code in the style of a 'normal' app (which is always running), and have everything taken care of for us in terms of deployment?

Containers for example are impressive and useful, but they further add to complexity in how our applications run. I'm a little surprised we're still having to talk about these concepts in 2018, when 10 years ago I'd have predicted the deployment process and its complications to be almost completely abstracted away from us.

  • Not all PaaS use containers as the unit of deployment; Cloud Foundry's application runtime treats the app as the unit of deployment, for example. – jonrsharpe Aug 7 '18 at 10:49
4

Taking your example of AWS, it can indeed manage the entire deployment process, including deploying the full environment from Cloud Formation config files through to the source code of the application. Code is pushed to git in Code Commit and then code pipelines will build the environment, compile the code, run integration tests and allow everything to be deployed from dev to test to live.

The same applies to other cloud offerings by other companies too.

But as you say:

The approach we take still says "we'll manage absolutely everything on our side in terms of packaging our app, how it will run, and then give the cloud platform the pieced together result to handle the actual running".

So the answer to your question is simple: you choose not to let it own the whole deployment process.

  • My understanding was Code Commit was just a Source Control offering, and you still wire it up to TeamCity etc to handle all the building, CF template creation etc. What is the AWS CI/CD service behind Code Commit called which rules out the need for this? And does Azure have an equivalent? – FBryant87 Aug 7 '18 at 11:39
  • 1
    @FBryant87 Code Commit is indeed just a git repo offering. You can then use code pipelines, triggered by a push, to carry out the CI/CD. – David Arno Aug 7 '18 at 11:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.