B (2:43)

Owen well, before we get into it, we could talk about why you might do it. You might have your own motivation, but in case you didn't, we took a look at some market research as preparation. There's a Gartner report on the cloud professional services market and IT estimates that cloud professional services, of which this is a big part, was valued at around $22 billion in 2023 and growing 16% every year, expected to grow at that rate for the next decade approximately. And this growth is driven by a few different factors, of course, the increasing adoption of cloud computing, governments and public sectors doing all sorts of digital transformation initiatives to catch up on their legacy tech, integration of AI and IoT into industries like financial services, and of course just increasing Internet connectivity all over the world. So for aspiring cloud architects, this growth really leads to a booming demand for expertise, especially in large scale cloud deployments and customized solutions. Because it's a growing market, other of people are going to be doing this kind of activity for the first time. So people who've done it before and have the skills to guide people along the path are going to be very valuable. So all in all, if you find this kind of work interesting, there should be many, many appealing career opportunities. So maybe let's just think about what does it mean to be a cloud architect. If you look at Google Cloud, they've got a definition defining a cloud architect as an IT expert responsible for developing, implementing and managing an organization's cloud architecture. So I don't know if that really tells us what we want to know, but maybe we can go a bit deeper. So cloud architect should really understand the specific characteristics of cloud environments because we're not just talking about architecture in general. That means crafting cloud architectures and strategies that not only meet present needs, but are optimized for future scalability, performance, cost, security, all of those pillars. So what it means then is that as part of as a cloud architect you should understand long term business requirements and be able to think about what the architecture and the cloud architecture means and a strategy that can fulfill those requirements today, but also iteratively as it evolves towards that future. As cloud platforms, your version one cloud platform is always simpler than it becomes. Over time they evolve, architectures will become more complex and diverse and then you have each cloud provider offering lots of different managed services. So this really means that cloud architects do need to understand like foundational architectural patterns which we'll talk a little bit more about later, but also be well versed in specific services and trade offs for a chosen cloud provider. And this is generally why we believe it's usually important to focus on one cloud provider. If you just take AWS alone, it has a massive surface area and it's unlikely for one individual to be able to master everything in AWS alone. So imagine trying to be proficient with multiple cloud providers at the same level of expertise. It's. Yeah, not really going to happen.

A (5:37)

Yeah. So if I can try to summarize what you just said and maybe add a little bit more. What we are saying is that cloud architect should be able to understand traditional system architecture and distributed system, then have an in depth knowledge of a specific cloud provider, let's say aws, Azure, Google, whatever you prefer, but pick one and stick to it. Also probably needs to have some good programming skills. Doesn't have to be the most well versed software engineer, but at least should be proficient with a scripted language like Python or JavaScript to be able to write some kind of automation or maybe write some code in terms of application code whenever it's needed. And then there are a mix of foundational pieces of knowledge that I think are required. For instance networking concepts, what is tcp, ip, DNS, HTTP, what a CDN does. All that kind of stuff becomes more and more important as you start to build more advanced architecture. Start Security we mentioned is always a requirement that is coming up and these days even more so. And that includes understanding identity, access, management, encryption. Again, networking in the sense of making network secure. Compliance as well is another topic that always comes up especially if you work in highly regulated industries. So an architect needs to have at least a basic understanding of what the different compliance regulation are kind of forcing you to do in your designs but also operative systems because of course, and this is especially true for Linux because tends to be the most used one when it comes to the cloud and application servers. So you probably need to understand some degree of all of that because almost every time when you're doing compute, although today maybe if you're using servers, there are several degrees of abstraction, but then you always end up needing some of that knowledge. And that means you need to understand what are the basic of the operative system, how does a process start? Memories versus storage. Probably you need to understand about containers, because that's also another common abstraction that you might end up using. Even if you're using, I don't know, Fargate for instance, which tends to be pretty abstracted, you still need to understand containers really well. And even more so if you end up using something like Kubernetes for example, then data storage and databases, that probably means understanding the difference between SQL and no SQL, or maybe even thinking about big data and data lakes. How do you design for those and when do you need one versus the other? And of course the main point is that you don't need to be a master in all of these topics because of course there is a massive surface there and it's going to take you years and years to become proficient with all of them, probably even unfeasible to become extremely proficient in all these areas. But at least you need to understand the basic concepts and try to think what are the pros and cons of all the different approaches and be able to come up with a design that makes sense. When you bring all these different pieces together, of course you're not going to be working alone, you will be working in a team and you'll be trying to draw expertise from all the components in your team. So probably you're going to have people that are experienced, really experienced with databases, for example. You will be drawing their experience whenever you need to design something at a lower level and you need more expertise. And that's something that of course you need to apply at all the different areas. Which kind of leads us to the next part, which is there are lots of soft skills that are required as well, because of course you need to work with a lot of different people. And this is not just technical, but most often you also need to work with business people, which means that you need to have some degree of business acumen. So you need to understand business requirements and objectives. So you need to understand how a business work and why certain decisions are made in a business. And then from the technology perspective, what can you do to support those decisions short term versus long term. And this involves sometimes taking kind of short term tactics, but at the same time having a vision for a long term strategy that allows the business to succeed long term. All of that stuff requires good communication skills. So can you talk technically with other technical stakeholders. But can you talk a little bit less technically with business stakeholders and make sure that you can bridge the gap between those two worlds, which effectively means communicate clearly. It's like one of the main things that you can develop from a soft skill perspective. And in more general terms, we can also talk about problem solving. At the end of the day, architecture is one of the many ways that you can think about problem solving in technology. It's maybe a little bit of a larger scale when it's compared to a single application. When you're thinking about architecture, you are solving a problem, generally a business problem, with an entire system, in this case in the cloud. So being able to understand what is exactly the problem we are trying to solve and what are the main challenges, and then build from there, I think is going to be a very, very important skill.

B (10:07)

One of the questions you might have is then, if you have an architect role, who is responsible for architecture? Is it always just the architect role? Do you have to be an architect to architect, or is architecture like a collaborative function of an entire team? And if so, what's the role of the architect within that team? Is it a final decision maker or is it a facilitator of architectural decisions? While a designated architect with the official title often leads the charge, decisions impact the entire team and beyond the team. Therefore the entire team should participate in that process. That's something we would really believe very strongly. Different roles and different backgrounds and levels of experience, and even looking at developers, operations, security engineers, testers, product owners, they all bring unique insights that are crucial for creating robust and effective architecture lectures. Even if an architect has the most experience, it doesn't mean that other people on the team don't have experiences they don't have. So it is important to be open and regarded as a collaborative activity. You have to resist the idea of an ivory tower architect that makes the decisions and hands them down for teams to implement that way isn't going to be very productive or a very enjoyable place to work. Even if you're not an architect, you should be able to contribute significantly to architectural decisions through your daily work. Even like, even as a junior developer, you should start to try and think about this and trying to understand how can I contribute here. You know, if you have something to say that you feel is relevant to the architecture, you should be open to doing that and your organization should be open to you doing that too. When everybody participates, then you get this sense of collective ownership. We've talked a good few times about before and responsibility for the architecture. So you got a lot more buy in, more satisfaction and you end up with a much more effective implementation and maintenance into the future then as well. Of course, if one person has the architecture and every decision has to go through them, you end up with a bottleneck that can slow down development significantly and make the architecture brittle. A team led approach will mitigate that. So in a way you could say that everyone could and should contribute to the cloud architecture efforts. It's not a solo act, it is more of a team sport. What's more important for an architect in the context is to set the vision and help to get mutual agreement on what it is you're trying to achieve in order to provide value. To think about the architectural strategy, how you were doing it and how it's going to evolve into the future as business needs evolve. And then things like setting guiding principles like scalability, security, maintainability and other ilities that can guide teams decisions. It can also be guiding frameworks for deciding on technologies to make it easier for people to not get stuck with analysis paralysis every time they need to pick up a new tool to do something. And also maybe encouraging people to avoid technology sprawl by having unique decisions every time you go to look at answering a problem. You know, architecture fundamentally it's like a game of trade offs. And I think more experienced architects understand that there's always trade offs in everything and that includes when it comes to decision making and collaboration. So you have to kind of understand and read the room as to when it's a good time to get people's opinion on board and spend more time discussing and also be able to say, okay, the time for discussion has happened now and we need to actually work together towards a decision to and facilitate that discussion, moving towards a conclusion so that you can actually get to work. So there's a lot of skills involved in there, but a lot of that will come with experience. So if you are an aspiring architect, that means that even with your current role you're already getting experience and you can probably find opportunities to do architect stuff.

A (13:33)

Maybe we can take now a little bit of a segue and share some of our stories. How did we become cloud architects? Actually we do have an entire episode dedicated to our personal journey that led us to become experience in AWS and eventually become AWS cloud architects. So we'll defer to that one for the details, but I think it's still useful to share a little bit of a quick summary just to give you two practical examples of how can you end up Becoming a cloud architect and it might be very different for you, but at least you have some reference points and you can draw hopefully some inspirations. By the way, that episode is episode 91 and we will have the link in the show notes. If you want to deep dive on our personal careers, I'm gonna take a stab starting my one. I think I consider myself very lucky because I discovered my passion for coding computers in general when I was very young. At the age of 12, I was accidentally playing with i386 computer and I realized there was Cubasic installed and I happened to have a book that was describing like how do you do like an yellow word? And then how do you draw a Christmas tree? This kind of silly things that I eventually. That eventually got myself into enjoying coding and building stuff. And I think since then I never stopped learning and I ended up eventually starting a career as a web developer. In between, I was also studying and I decided to take a degree in computer science, which is something that I think helped me to have a strong foundation in programming and software engineering in general. And I was also working while studying, so I ended up working in various software engineering and web development roles. And I continued that of course, after my degree. So I think I had more of a decade or something close to that of experience in different environments as an employee, working for various companies, working as a freelance. I even had my own startup which failed miserably. But that's an entirely different story that I'm not going to cover today. And at some point in my career after all these things, I think was around 2016, I found myself working in a small startup that needed to build a product in the cloud. And I think it was quite of a unique opportunity for me because in that team, which was a very small team, I think we were like four developers. Nobody really had strong expertise with the cloud. So we kind of had to figure it out together and deploy something on aws, which was a bit scary because of course we felt the responsibility, but at the same time by taking the leap, it was the first step for me to start to learn and embrace this new world, which I think eventually led me to become an AWS expert. Also fair to say that we were not necessarily alone all the time. We used to a consulting company that helped us to kind of set the foundation right, which is another reason why you should consider doing that. If you find yourself in this situation where you need to do something on aws, you don't necessarily have all the expertise in house. An external company can help you to set the foundation right and quickly upskill your team. So I found that experience very useful when I was on the other side at that time. So I guess from that moment on, I always found myself doing more and more aws, both as personal interests, but also because I ended up working in more companies where we were effectively shipping more and more complex products on aws. And while I was doing that, I was trying to learn as much as possible not just about building web apps for the cloud, but also how do you architect entire systems with multiple components to run smoothly in the cloud in a secure way, scalable way, doing all the observability, all this kind of stuff that I think eventually is the main responsibility of a cloud architect. So after I think a few years of all of that, probably about four to five years, I joined for Theorem, and at that point I got an official title of Cloud Architect. So thank you for Theorem for giving me the trust. But I want to say that even though now this is the title I still get to code almost every day. It's something that I enjoy doing. And I think it's a fundamental thing for an architect to still be able to build, not just design, but actually keep building together with the rest of the team. So I think it's. One last thing I want to mention is that throughout all this journey, I always looked for opportunity to do content creation. Maybe just because it's something else that I enjoy doing, but at the same time, maybe I didn't realize that, but I think that helped a lot my journey into becoming an architect, because in many ways it kind of helped me to develop communication skills. I ended up delivering talks at various conferences. I even co authored a couple of books. And I think all of this stuff, in a way or another, gives you the skills that you need when you need to communicate in a verbal or in a written form with your peers, whether these are technical or from the business side. I think that's something you need to figure out. How do I improve on that skill? And in my case, that was content creation in the broader sense. This was maybe a little bit longer than I expected, but I'll switch to you, Aoi.

B (18:14)

I don't know. If we do it again next year, it'll be even longer because the story isn't finished yet. Yeah, I mean, I also have a fairly privileged and fortunate background in that got into programming early and also studied computer science, which really, you know, gave a good foundation. I didn't appreciate it at the time at all, but never really thought much about Architecture until I got into industry and started working because it was all about programming and software development and I didn't really understand what a software architect was. We had some, when I was in college, did start learning about design patterns and pattern languages and how all that stuff evolved. But it's not really until you understand, especially building larger systems, which you don't always get exposure to early on. Actually in my career, I think one of the things that shaped my biases that I have now was for many years I built a lot of systems and most of them, a remarkable number of them, never made it really into the real world. And that can happen, you know, you can. A lot of software does not make it into production or doesn't make it either because it's in a startup or because it's. You work on versions of systems or innovative projects that just don't make it out into the real world. And after, you know, a good few years in the industry, I look back and thought, wow, like there's actually very little of the work that I've been involved in that really made it into the real world. And that kind of led me to, I suppose, more of a contrarian approach as an architect where always question the value of what we're doing before we're doing it and wonder if it's really worth doing. And because I just, after a time I said, okay, I'm going to have to flip this ratio and ensure that the systems I work on, most of them are going to see the light of day and not end up on a shelf gathering dust. After working as a developer for years, I was constantly thinking, oh well, I should think about becoming a senior developer and then an architect, as if there's this natural progression and you're just ticking off boxes on the way. And when I look back now, like I'm still developing as a developer, as there is no milestone really I can say I've reached at any different point. It's just after a bit of experience, you, you feel more and more comfortable doing all these different roles. And I don't feel like I'm there yet in any regard on any of these things. It's just constantly learning and either becoming more comfortable with them or just getting more uncomfortable with Imposter syndrome or not knowing what you're doing. That always helps, right? Because ultimately architecture is often just a question of making decisions. And being able to make a decision doesn't just mean that you know what you're doing. It means that you've got the ability to say, okay, there's different trade offs here, but let's just pick something and run with it and then if it doesn't work, we'll try something else. I don't know if that was a clear description of my journey, but that's certainly what comes to mind right now.

A (20:55)

Yeah, it's super interesting. I like that you took a slightly step by step approach and tried to give a little bit more of a guidance on what are the things that matter, or at least what are the things that matter in your journey that led you where you are today. Let's get back now into something a little bit more practical because we want to share a potential path and some resources that might help you if you are really decided now that architecture, cloud architecture, is what you want to achieve this year. Starting this year, what are the steps that you can follow? And again, remember the disclaimer that this is just a suggestion. It's not necessarily the most complete or the most structured path, just things that you can draw from. So one thing that is worth mentioning is that if you are already a software developer, maybe already working in the cloud, you are already on a great path. So that's a great starting point because that means that you are already getting lots of experience and this is setting you up for making the leap and becoming a cloud architect. So one thing that you could start to do, and you are probably already doing, maybe without realizing it, is try to gain more experience with as many solutions system architecture environments as possible. Because effectively being able to recognize different options and the pros and cons of every option is one of the main qualities that an architect needs to have because they kind of gives you that breadth and depth of understanding of how different system works and how can they be connected together. But of course this is not necessarily a starting point. Maybe you are starting from somewhere else, maybe you are even transitioning from a totally different career. That's still fine. It doesn't mean you cannot achieve the goal. The goal is still totally achievable, but maybe you need to follow a little bit of a more structured approach where you need to figure out exactly what to learn. And then of course, as you keep learning and as you keep practicing, eventually you will have enough confidence and enough knowledge to be on the job with the title. So of course this is going to take some time, it's not going to happen everything on day one. So be patient and try to dedicate a little bit of time consistently and eventually you'll get there. My other suggestion is that there is always a struggle between theory and practice, it's difficult to find a good balance, but I think it is important to have both. Some people just focus totally on the practice and they miss some important theory aspects. Also, the opposite can happen. You do only theory, you think you know everything and then when you try to do something in practice you don't even know where to start. So trying to find a balance and my suggestion would be learn something from the theory but in small steps and then try to have practical experience as quick as possible to consolidate those learnings. So with that being said, let's focus on some resources that can guide you along the way. I think if you want to focus just on cloud and architecture aspects, there are two great resources that I want to suggest. One is the AWS well architected framework, something that we have been speaking about before. There is an entire episode, episode 68 that talks about the structure of the well architected framework, what it does and why AWS created this. But just as a quick summary is effectively a piece of documentation with lots of resources for architects and aspiring architects that is structured in multiple pillars covering things like operational excellence. So how do you run and monitor systems security reliability, for instance, how do you design for failure performance cost optimization and the more recent one is sustainability. So how do you design systems that are sustainable sustain? So this is a great resource, absolutely recommended, so go and check it out whenever you have time. The other one is actually from Azure, so maybe a little bit surprising for people that follow this podcast, but I think it's a very, very good resource. So absolutely worth a shout. And it's called Azure Cloud Design Patterns and it's just a documentation page in the Azure website. We'll have a link in the show notes which illustrates a few common design fallacies that people do in regular software engineering, but I would say even more so in the cloud, which are things like assuming that the network is always reliable, bandwidth is always infinite, topology never changes, all these kind of common mistakes that when you actually start to think that those assumptions are not true, actually that's when you start to go deeper into your architecture and thinking okay, if this thing is never going to be 100% reliable, how can I design my solution to also be somewhat available when things are not reliable around it? And of course it's not an easy thing to do, but just thinking about it is going to give you lots of idea and then of course you can look at the industry and figure out how other people are solving this kind of problems. And that's why I also like this specific resource because it gives you a list of common architectural patterns that with very good descriptions and examples that you can quickly browse and just have a feeling for how many solutions already exist in the industry. And you can often just take those solutions and combine them together to solve your specific problems. And just to give you some examples, I'm talking about for instance the anti corruption layer, cqrs, orchestration versus choreography, the request response patterns, synchronous and asynchronous. So all this stuff, I think it's something that you will find yourself using every day when thinking about architectures, distributed.

B (25:48)

Systems and kind of systems thinking. System architecture is another important thing to think about. Cloud architectures are systems ultimately and you need to connect different building blocks to come up with a scalable solution. So that really means not just with cloud architecture, but any modern architecture. Understanding messaging like pull versus push event buses, queuing systems, we've a suite of episodes on those for AWS and then also fault tolerance for inter process communication, data persistence, retries, idempotency, circuit breakers, all that kind of stuff. In general, every problem might have a few different solutions. So you'll need to generally have a good understanding of different patterns and the trade offs in terms of performance, security, robustness, cost, etc. This way you could pick the most fitting approach for the specific problem at hand and we'll have some resources, some great books that you can read if this is something you want to brush up on. But I think data, data storage, database and Designing with Data Thinking about Dataverse is a really good one. What should we say there, Luciana?

A (26:44)

Yeah, I think that the main realization that I personally had is that almost every single application or solution that I ever designed required to persist data in a way or another. And of course there are lots of different trade offs and lots of different ways you can do that. So the business needs might vary a lot and therefore you need to figure out, okay, how do I effectively make sure that I'm satisfying those business needs? Like for instance, sometimes the data needs to always be super accurate and fresh. So how do I design a data storage that can fulfill that particular need? Sometimes you need to deal with large volumes of data. How can I design a system that scales to support those large volumes? Other times you need to keep the entire history of changes for a long period of time because maybe, I don't know, you need like an audit trail. How can I implement that audit trail into my solution? And I think one of the realizations that I had at some point in my career is that I always thought, okay, I need to find the perfect database that can solve all these problems, then learn that database really, really well, and then I can build anything. But the reality is, of course, more complex than that because there isn't really one solution that fits all them all. So you really need to understand what are the different solutions in the market, what are they good at? And then based on your requirements, very often you need to combine multiple solutions to try to get the best of the different trade offs right, which can bring other complexity because sometimes when you have multiple data storages, you might have a problem of how do I synchronize the data if I need to synchronize it across multiple systems? Or maybe you need to query multiple data sources to come up with a view that makes sense in your application. So all this stuff is something that you will learn with experience. But the point is, try to think about again, what is it that you're trying to solve? What are the business requirements and what tools are available that can help you? Probably you need a combination of these tools for the specific use case. I'm not going to bore you with the cap theorem, but it's another thing that is probably worth understanding and exploring. And it's the idea that by design distributed storage system distributed databases cannot have all the qualities that you might expect from databases. You can only pick two out of three between consistency, availability and partition tolerance. And that's why there are very different classes of databases with different characteristics. So you can pick whichever one makes the most sense for your use case and your data storage needs. There is a very good book called Designing Data Intensive Applications by Martin Kleppman. It's the very famous red book with the boar on the COVID So chances are you have seen that online. I think that's a very good read. If you want to kind of broaden your mind into thinking about storing data and all the different requirements you might have to deal with, which is something that becomes more and more important for architects.

B (29:21)

And when you've got to think about distributed data distributed systems, you have to think about networks, because that's how you distribute things. And an understanding of networking is an important thing to have in your toolbox. You should really understand, like IP addressing and subnetting, the basics of networking, the OSI stack, tcp, IP to some degree DNS, and of course HTTP, which is ubiquitous. A personal litmus test there is. Could you explain everything that happens? This is a classic interview question. Could you explain everything that happens when you run a query on Google and hit Enter in your browser or enter a URL into the URL bar. Can you describe all of the steps that happens and all the different network layers and protocols that result in a search result coming back for you? And we'll have a pretty good guide from AWS in the show. Notes for networking essentials now you've mentioned operating systems as an important tool. Is that still the case even with all these layers of abstraction?

A (30:20)

Luciana yeah, you might make the point that it's becoming less and less important because of course there are more and more abstraction like function as a service will abstract most of what you need to know generally about the operative system, the operating system. But I still think that there is a very strong reason why you should understand at least the basics, because I think you're never going to get rid of things like, I don't know, even just understanding how does a process start. This is still something you need to understand even with something like Lambda, because in some cases it will actually help you to troubleshoot why a lambda is not working, or maybe to achieve certain things with your Lambda. Or another trivial example is do you understand the difference, for instance, between memory and storage and the different trade offs that can happen there? You might end up writing a lambda that requires a lot of memory, just because maybe you are not really paying attention to the design of that particular piece of software and then maybe it just crashes at runtime and you don't know why. So I think those are still things that you should have some basic understanding of. Maybe you don't need to become an expert in Linux or Operating system in general, but you should know all of this stuff. Another thing that is also relevant in this space is Docker or Containers in general terms, because that's another very common way to ship software in the cloud. You might be using something like Fargate, which abstracts the container workloads a little bit, but you still need to know quite a lot about, for instance, how Docker works, how to create a container, how to provision and run container, how to give it memory permissions, and so on. And even more so if you end up designing for something like Kubernetes. I think in that case you need to know even more about containers and operating systems. There are actually two resources that I want to suggest. One is the Docker curriculum, which is a free resource that you can find in. I think it's part of the Docker official documentation. We'll have a link in the show notes and that gives you a very good and in depth overview of how Docker works and how you can practically use it to build applications. And then there is a book that I happened to read some time ago which is actually quite nice and it's called How Linux Works by Brian Ward. Again we'll have the link in the show notes.

B (32:23)

Okay, well two other quick things quickly then. On the hard skills side are of course programming. We mentioned it. A lot of architects don't get the opportunity to or don't feel they have to develop software. We think you should try to do as much as you can. Obviously that's just our take for our context isn't the same in all companies. You don't have to take our word for it. But the more hands on experience you have, the more you'll be able to relate to and communicate with other members of the team. We'll have some links to help you with that. And then security I think is something that's unavoidable as a skill for an architect. It's becoming the number one toolkit tool in the toolkit really is understanding security threat modeling. You don't have to be the expert, but you do have to understand who to ask, where to look and when to consider security. So given those two hard skills, should we talk very quickly about soft skills?

A (33:08)

Luciano? Absolutely. And we already mentioned that this is becoming more and more of a something that it's being acknowledged in the industry that you need to have soft skills. You need to be able to communicate well to be successful in this kind of careers. I think it's true for every type of technical career. But of course when you are aiming to be an architect you are more exposed to be forward facing and talking with different people, both technical and non technical. So of course you need to have those skills. I was actually very surprised. While I was looking online to prepare the notes for this episode, I discovered that there is a university. I'm not going to make the name just because we don't want to necessarily advertise that is a technical university like a software engineering university. They have an entire course on soft skills and they try to cover things like communication in terms of active listening and clarity, collaboration in cross functional teams, self awareness, self regulation, empathy and relationship management. I was really surprised to see all this topic being so explicitly covered in a technology type of degree. So this is great to see and I think we should be putting more attention to these topics even inside companies. We should encourage people to talk more about these kind of things and to have ways to help people develop these skills because I think Everyone is going to benefit from that. There are a few interesting books that I think are relevant here. We'll have the links in the show notes for you to check them out later. So I think we are getting close to the end. So how do we give people a little bit more guidance to put things into practice?

B (34:29)

Well, there's a lot of theory, but in order to try and think about putting it into practice, we would recommend you try learning in small increments and try to do some practice to consolidate every topic you learn. We had an episode, episode 58 where we gave just some examples of project ideas to explore and concepts in the space of web application development, machine learning and data science. But if you're already working in the industry in other roles, I would try and actively seek out opportunities to work more closely with architects in your company and learn from them.

A (34:58)

I'm going to give you a quick list of things you can do that are a little bit more practical and again, feel free to try other things. This is just one potential path you'll need to learn core concepts, system architecture, databases, networking, security and so on. I would suggest try to find courses online, for instance in a cloud guru, Udemy Coursera, whatever that the web is plenty of resources or books or whatever resource works for you, but try to be methodical and spend two weeks for every one of these topics and then maybe come back on rotation to learn more. Don't just try to focus on one topic for a long time because of course that topic can be endless and you don't want to find yourself in a rabbit hole where you're not progressing and building that more holistic view of these foundational topics. In terms of programming skills, there is plenty of resources. We'll have some in the show notes that can help you to practice. I would say try to do a few coding challenges per week, even just one, but at least get into the habit of doing it recurringly. Especially if coding is not something that you get to do a lot in your daily job. Try to build that habit so that you have the confidence and you learn to think in terms of solving problems with code for aws, there is a lot to learn there and you might decide to take a certification to have a more guided path or just try to explore the different services one by one. Again, the goal is not to become an expert in every single service, but just to explore a little bit the surface and understand the use cases. So the same suggestion applies. Try to invest a limited amount of time, maybe a week, on a few fundamental Services one at a time. Maybe you start with EC2, for instance, for a week, then you try S3 for another week, then you try something else for another week. I think at some point we realized that there are some services that are more fundamental than others. At least that was for me, the case. For instance, with iam. Everything I was doing, I needed to deal with iam. And then at that point I think it makes sense to spend a little bit more time on those services, deep dive and really understand how they work and how they can be integrated with the others. Finally, I would say build a portfolio. If you are building stuff, why not just publishing it, for instance on GitHub or maybe write an article that describes your experience. All of that stuff is going to solve two purposes. One is going to help you to consolidate your ideas, but also if you ever need to showcase what you built, you already have it there and it's nicely polished and you can talk through about that with people. This is great. If you are maybe you want to start to work, you want to start a solo career as a consultant, you can use that as a way to showcase your potential customers that you know your stuff. Or maybe if you are just trying to get hired into a company so you can bring into an interview to prove that you learned something useful for the job. And finally, networking and community will go a long way. Thankfully, in the AWS space there is a lot of activity going on. There are AWS user groups both online and physically. There is a webpage published on aws with almost 600 user groups. So most likely there will be one close to you. And if not, you can probably join some of the remote ones. So we'll have a link in the show notes. Okay, and that brings us to the end of this episode. And I will say that becoming a cloud architect is definitely not a get rich quick scheme. It's more like an ongoing adventure. You need to be patient and keep learning, growing and constantly adapting to new changes. So of course it's something that you should start today, but you probably never stop. And that's actually the thing that we personally love. We have been doing this job for a while, but we still feel we. We haven't reached the point where we could say, oh, we are the perfect cloud architect. We are still learning every day. There is a lot that we don't know. There is a lot of experimenting and trying to figure out what's the best solution. And I think that's probably the best part of this role, that you are always working with people and trying to solve problems together and every time you get a little bit better at it. So we hope this episode has been useful and we look forward to hearing about your journey as a cloud architect. So don't be shy and reach out to us and let us know how it is going, how you are progressing and what are you thinking to do next. So thank you so much for hanging out with us today. And until next time, epic cloud architecting.