Okay. Hello, everybody. I'm Juanillo Lott. I'm a software engineer at N0. I'm also part
of the open-to-full core team members and who want to show up hands who is using infrastructure
as code today. Nice. Who is considering using infrastructure as code maybe didn't start
yet? Okay. Great. So, today we'll talk about infrastructure as code and why we need it.
We will choose how to choose the right infrastructure as code for our needs, how our organization
maturity should affect the decision and will discuss the unified DevOps process, meaning
how we integrate our infrastructure as code into our CICD pipeline. So, I'll start with
a story 12 years ago. I nailed my first software engineering job in an on-prem organization.
Everything was completely air-gapped and our architecture was pretty simple and look like
what you see on the left. We had bare metal servers with virtualization layer and on top
with some back-and-up locations, all behind one load balancer, one centralized database and a few
cues maybe. And one day I went to the office and I opened my web application that I was working
on but I kept getting five or two status, that gateway and I called the IT guy and after a
few minutes it told me, I'm sorry we can't find the physical server that your application
was hosted upon. So, it ended up with me going down to the data center with this person
just searching for the missing server which we never found. Yeah. Lovely. So, that's why scaling
was really hard. My organization had to keep maintain our hardware hardware and physical
servers but then cloud computing entered our life and now architecture looks more like
what you see on the left side, left side. And it wasn't just cloud computing, thermal
factors to wire architecture became more and more complex. If it's the shift from water
full to agile we keep developing in more iterative cycles so we keep adding new features. If
it's the DevOps approach and now we're trying to automate everything and of course, monolith
the microservices, the shift in this approach and sure that our infrastructure was broken into
multiple part, each microservice has its own infrastructure. From a single database we have multiple
fragmented databases so everything became more and more complex. And at the beginning of the cloud
computing era, click ups was enough but then as things get getting more and more complex,
infrastructure's code was introduced and the idea behind infrastructure's code is that
practices that are good for developers are good for DevOps people, if it we have one document
it's in the source of truth. Now it's really easy to understand how our infrastructure should
look like. It's really easy to promote it between different environments if it development integration
production and we also have we can automate it and we have version control and we know who did what
and why. Hopefully if they really wrote the correct commit message. Let's take a quick look at
the infrastructure's code timeline. This is a very partial timeline there are so many different
tools out there and the beginning of infrastructure's code we had very simple scripting if it was
bash and python but then the first infrastructure's code tool came to exist and they were more
dedicated and focused on managing existing configuration but then and it's like for example
public puppets and chef existing resources and then in 2010 a cloud formation entered our life
and changed and shifted the balance and now some infrastructure's code tool are more focused
on creating and provisioning new resources. In ever since we have lots and lots of tools that we
will cover in a minute. Awesome so we need to choose the right tool right we have so many considerations
just a few of them. It's security and compliance if we accidentally misconfigure our
infrastructure's code tool the server like our internal application can be exposed to the
internet people can maybe get their hands on information that we don't want them to.
If it's state management some infrastructure is good tool have to manage some kind of a state
to keep track of all the resources all our architecture and we need to understand how they manage
that sometimes we need to manage that sometimes it contains sensitive secrets and scale and
performance I don't need to tell you how knowing it is to wait for something to deploy for a long
or especially if we have a production issue and we need to fix something right here right now
and of course learning curve and adoption is a very important consideration if it's to complex
people want adopted and we need to have proper documentation community support tooling and
ecosystem to ensure quick adoption. So this is where you kind of imagine mortal combat music
and we will discuss and we will cover six tools we have an overwhelming amount of tools here
I personally use most of them but there are so many option outs out there and let's talk about six
of them so we have terraform it's really an industry standard through initial of hands
who is using terraform in here yeah very expected it's cloud agnostic but not only cloud agnostic
you have providers for everything for SaaS solutions for example off zero my company and zero
also have a terraform provider also Kubernetes it can even order pizza with a terraform provider
it has a very large community and ecosystem and lots of tools around that and and best practices
and documentation encourage you to build really modular and reusable infrastructure you have
lots of models online that you can already use I put it in the grave because I think there is no
consensus around that some people love the domain specific language the terraform users
ACL some people really don't like people usually who don't come from programming backgrounds
tend to love it because it's declarative and really really easy but programmers don't like it
because it takes some of their freedom personally as a programmer who shifted into platform
engineer I I think it's very very like useful and very easy to use
preference and scalability I put it in grave because it's really not bad compared to other tools
but when your state become really large and your infrastructure become quite complex it can be
kind of slow but you need to manage your own state file and which means like you really have to
understand where you want to host it it's not encrypted everything is in plain take text so you need to
also understand how you encrypt it and it used to be open source but change to be a cell in
last August 2020 you know August 2020 for you already yeah and the next tool is called
formation maintain by AWS so it means that the vendor is the one responsible for the documentation
best practices which is really nice state is managed behind a scene can be a pro and a con
I personally never had a problem with the state so I I like it AWS added new features recently
built in drift detection get ups flows and when it comes to syntax we really have like a
YAMO usually it's a YAMO configuration also a declarative one which I personally find less
simple than terraform let's friendly less friendly to use and the bad stuff it only support AWS
cloud yeah you can deploy things to like other providers you can't order pizza with that
and the language is less friendly when trying to create modeling infrastructure from my from my experience
next tool will you me it's quite an interesting one because you use your use like
familiar languages type great Python go to write and describe your infrastructure code
very when comes to provider it's very very similar to terraform it's cloud agnostic you have multiple
terraform multiple providers also some of them based on terraform some of them are based on terraform
providers there are multiple ways to manage your state they can manage it automatically for you and
then they also encrypted or you can manually manage it on your own because it uses code and functions
it's really easy to create modularization and in here it's again it's in gray because the language
familiarity can be very good for developers but devops people can really struggle with learning new
programming language it's a last popular tool community size and support is smaller and performers
also on big deployments can suffer and like my take is that I like guardrails when I have limitations
then I feel safer I feel like I can't over complex my architecture and one of me kind of gives me
in my opinion too much freedom that I don't always want and we will be comparing that to open
tofu as I said before but again you diligence part of the open tofu core team for the last
year and a little um open tofu is a drop in replacements for terraform after the change of the license
of fashie corp it's truly open sorry it's backed by the links foundation that's white will always
remain open source because it's like it's a fork of terraform so it inherited all the terraform
the extensive terraform at the system um we have like one of the first features we implemented in
one dot seven was taken encryption to ensure that you that you can encrypt your secrets in your state
at rest um so they won't be in plain text and as mentioned about terraform we farm
it's a domain specific the clarity of language performs a scalability it's pretty much the same
although we're trying with the community to improve that and obviously it's why it's a new tool
there is a relatively small but growing community and I think it still needs to prove itself
um our last comparison Ansible so this one is a little different because as we said
we have uh infrastructures go to that provision resources but Ansible is dedicated to
configuring two configuration management um built in Python but configuration language is in
yamo uh you write procedural playbooks declaring what to do in each step it's agent less so you
don't have to now handle installation and updates of agents although you have to um enable
as a sage um in order for your service to communicate um and it's an open source tool with a
very large community and um thousands of Ansible Galaxy roles that you can use online um but it
has no state management so it runs everything every single time um because it can compare it to an
existing state let's compare it to sold project it is a similar solution um it uses server
client configuration um that can require agents but not always um on the other so we you don't have
to enable SSH and it's quite fast um it's faster than Ansible from what we've used and it
uses state for configuration management um again but usually you'll have agents so you need to maintain
and and ensure updates are going smoothly um it was also acquired by uh VMware and Brotscom so
it's fully open source now but uh let's see what will happen i hope it will stay it with the
way it is uh so it's really after we talked about those tools it's really really tempting uh to ask which
tool is the best and as always the answer is it really depends there is not really a best tool for
all scenarios as we said there are lots of questions that you need to to understand based on your
organization what platforms are you using what cloud are you using multiple clouds uh who will
mean maintain the infrastructure scope if it's developers if it's uh maybe the DevOps team and what
technologies they're familiar to and we should always consider mixing and matching tools um yeah so
we should always mix and match uh consider mixing and matching tools and create solutions that are
more tailored for our needs um so as we said some tools have different focus for visioning
new resources managing existing ones we can mix and match them taro form an open tofu has an
emcible provider which is cool um and in all the companies I've ever worked in uh they were always
multiple uh tools that were used sometimes like for example infrastructures code that um was maintained
by developers um was written in plume for example and maybe the more uh general infrastructure
is called for the whole organization that was maintained by the DevOps team was written in uh terraform
awesome so we need to take a look at our organizations uh maturity to understand how we use
our infrastructures code tool really depends when we start usually and the there gets an organization
is really really small uh we probably start with click-ups um but then when it doesn't cut in any more
it's ideal time to really start using some kind of an infrastructure scope but with manual
deployments on our local computers um but there is like sometimes something there there come the time
multiple people start working on that infrastructure is code uh maybe we want multiple people to
deploy our infrastructures code but you don't want them to have access to uh sensitive secrets
so that's when we we just start thinking about uh automation and maybe uh taking the infrastructure
is code uh tools and automating their deployments as part of our CICD uh and the last stage I think
that's where your infrastructure becomes a bottleneck in your organization that's when the time
to consider a more extensive platform if it's in-house you can also buy an existing tool um to receive
better governance and self-service um capabilities so we are focusing on stage two when we want to
start creating automation around our infrastructures code so let's see how our safety pipeline will
look like so we first write code we push it we're probably open a poor request so other people can
can see what we're about to change they can validate that this changes are uh good and then we
uh then we have CICD steps so we can use LinkedIn testing and we will discuss uh a few tools here
if it's infrequest and check off on how we make our CICD pipeline with an infrastructure
code even even better um then after that we can use a approval policies to to validate that
our plan what the thing that is about to change is okay is um following policies of our organization
and only when this is fine the automatic um approval flow uh succeeded and as somebody
approves our poor request we can apply and keep monitoring our infrastructure so um let's we'll
briefly talk about um some tools as I said that can help our infrastructures code uh CICD
and come even better if it's check off it's a study code analysis tool um that scans our
infrastructure is good for misconfiguration security vulnerabilities um and we can write our own policies
or use uh extensive policies and intro for example that our internal our institute is not
exposed to the whole world um and another very cool tool is infrequest um we can use it to
actually know if the thing we are about to deploy how much it will cost us obviously it's
can't anticipate usage costs but it can finally if we're about to for example it actually
happened in my company uh somebody accidentally deployed a very um pricey radius um instance and
if we like we could have used that but thank you and we would have picked right up on that
and see how much it's about to cost us um i think it's it's so we can integrate like for example
we have OPA OPA policy agent and it's a policy is code agent and we can write our own policies
and now we don't we can reduce bottleneck of human approval because they will be automatically
checked and decide if we um if this policies if if this code is fine if the sting is okay or not
um and it's really nice because you can actually integrate OPA with infrecost and maybe create
some kind of policies um and budgeting around um if people are about to go over budget from
something like that okay so in summary um we've discussed different types of
infrastructures code tools we said there is no best uh tool for all the scenarios and it really
depends on our organization maturity level the technology stackers we're using our use cases and
requirements um and we should always adopt a strategic and adaptable approach when choosing our
infrastructures go to thank you do you have any questions
honestly yeah i should repeat the question so um the gentleman asked me
why didn't i management mentions cross plane and if i've ever worked with it honestly i never did
but i think it's a very very cool tool um lots of people and other DevOps that i'm working with
are using it to um to simplify the um their infrastructure is code for developers for example my husband
he's like he likes to use terraform an open tofu but um when he wants to give access to developers
in an organization um he started creating a very simplified approach using um cross plane so it's a
very cool tool but still have unused that next question yes yes so uh you get a free
here so yeah okay yeah so he he asked me why i i i i i i i am contributing to open tofu
why decided to do that so m0 is one of the founders of open tofu it's one of the backing
companies or had was the one who started the rco the one who started the manifesto uh when
hashicorp changed the license that's really the thing that got everything rolling and open
tofu to its creation and honestly i just saw an amazing opportunity i've been using terraform for
years and i love this tool and i just came to my boss and i'm like can i please please work on that
i know that we need to uh to to give like to to um donate some developers to work on that and i asked
and they let me do that and this it was like the last year was really amazing first time i've
been working in an open source getting in touch with the community creating all sorts of relationships
uh if it's with uh jet brains because one is support for open tofu looking at the viscode extension
it was really really interesting next question yes yes
as a class manager we see uh open tofu for terraform as uh diverging off which is going to be happening
how do we what's your take on maintaining an environment that supports both these use cases
yeah so a so um i was asked how the um if that's what i want to touch if terraform
an open tofu are a divergence and how to really support like an ecosystem around the two of them
right is that correct okay so as an open tofu maintainer we're really trying not not to
diverge from terraform like when it comes to providers and models uh it is the same
ecosystem was still support all the models and providers of terraform and we uh we want to keep doing
that like that's that's the big advantage of open tofu because we have this amazing ecosystem
and we understand that and we're not taking divergence uh in any um like likely
so usually what we're trying to do we're trying to create new features but also
support some features that terraform also released to ensure there is a very good compatibility
between terraform and open tofu and that a users can switch back and forth pretty easily
but how can you but that's a good question what if you want to like if you have a giant
and you want some of your infrastructure's code to be a reading open tofu is something to
use terraform actually we created a new feature not that new like a feature on that is called
it's called dottofu you can set some configuration as dottofu and then open tofu will be the
one um who reads them and ignores the respective uh TFiles so there are ways to um and practices to do
that I think it's written more in our in our website
times up thank you so much