Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Luciano: Happy 2025 to all the listeners of AWS Bites podcast. We are back from the holidays, recharged, and ready to dive into another fascinating topic in the world of cloud computing and AWS. My name is Luciano, and today I'm joined by Eoin to discuss a subject that we get asked about all the time. How do I become a cloud architect? And this is really important because the start of a new year is the perfect time for resolutions and career shifts, which makes it the ideal moment to explore this exciting and rewarding career path.
While we don't claim to have all the perfect formula to make you the perfect architect, we are excited to share our personal experiences, discuss the journey that led us to become cloud architects, and outline what we believe are the key skills and traits that are essential for aspiring cloud architects. We'll map out a practical roadmap, and we'll try to give you some of the details that should guide you from zero to cloud architect in 2025.
And we will also try towards the end to answer some commonly asked questions. So let's tackle those new year resolution, and let's jump right in. AWS Bites is proudly brought to you by fourTheorem, an AWS consulting partner dedicated to helping you and your team to deliver successful projects on AWS. With a sharp focus on performance and cost optimization, we are here to ensure your cloud journey is smooth and efficient.
If you're searching for a trusted partner to bring your AWS projects to life, visit us at fourtheorem.com, and let's work together to make your vision a reality. Okay, so before getting started, I want to share some disclaimers just to set the stage. We are experts on AWS, and therefore this episode, of course, is going to be focused on AWS. Although this concept, this topic of becoming a cloud architect, of course, goes beyond just AWS.
Everything we're sharing today, you can probably take most of it and also apply it if you are exploring a career for other cloud providers. Maybe that's Google, maybe that's Azure, maybe that's something else. Hopefully, what we can share today is mostly going to apply to all of that as well. Now, becoming a cloud architect isn't really or necessarily a straight path. There are probably many, many different trajectories that you can take to land there.
It's also a relatively new specialization. We don't even think there is like a canonical educational path if you want to go through like a university and just come out as a cloud architect. We don't believe that that exists today. So what we can do is we'll try to share our opinion and our experience. And hopefully after listening to this episode, you'll know enough and you can explore a little bit of the topic more and eventually come up with a more complete view and some kind of path that you can start to walk to get closer to this goal. As always, this is just the starting point for our conversation. So we are going to encourage you to ask any questions or leave comments, share your experience. And we want to turn this into something that is driven by everyone and not just by our opinion. So please reach out. Where do we start, Eoin?
Eoin: 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, lots 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 a 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 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.
But 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.
Luciano: 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 a 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.
Security, we mentioned, is always a requirement that's 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 regulations are kind of forcing you to do in your designs, but also operative systems because of course, this is especially true for Linux because it 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 basics 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 NoSQL, 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 and 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 that really, 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 works 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 at a little bit of a larger scale when it's compared to a single application. When you're thinking about architecture we 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.
Eoin: 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?
Now 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 architectures.
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 regard it 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. And that way isn't going to be a 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 as a junior developer you should start to try and think about this and trying to understand how can I contribute here. If you have something to say that you feel is relevant to the architecture you should be open to doing that and your organisation 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've got a lot more buy-in a lot 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 architectural view 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're 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 illities 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 and facilitate that discussion moving towards a conclusion so that you can actually get to work and 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 could probably find opportunities to do architect stuff.
Luciano: 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 will 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 a i386 computer and I realized there was QBasic installed and I happened to have a book that was describing like how do you do like an L award and then how do you draw a Christmas tree this kind of silly things that I eventually got that eventually got myself into enjoying coding and build this 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 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 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 interest 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 and 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 Eoin
Eoin: 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 looked 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 of 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 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 some 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 clearer description of my journey but that's certainly what comes to mind right now
Luciano: 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 but 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 trying to gain more experience with as many solutions systems 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 it kind of gives you that breadth and depth of understanding of how different systems work 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 it's 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 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 think 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 ideas 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
Eoin: distributed systems and kind of systems thinking system architecture is another important thing to think about cloud architectures or systems ultimately and you need to connect different building blocks to come up with a scale of a solution so that really means not just for cloud architecture but any modern architecture understanding messaging like pull versus push event brushes queuing systems we've a suite of episodes on those for AWS and then also fault tolerance for inter-process communication data persistence retries item potency 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 thinking about data first is a really good one what should we say there Luciano?
Luciano: 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 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 cover 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.
Eoin: Something that becomes more and more important for architects 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 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 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 Luciano?
Luciano: 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 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 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 I think it's part of the Docker official documentation we'll have a link in the show notes and that gives 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
Eoin: 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 modelling 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 Luciano?
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 and 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
Eoin: 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
Luciano: and learn from them 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 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 you will realize 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 web page 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 reach 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 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 happy cloud architecting.