Free Short Course: Masterclass: Comparative Cloud Technologies - Module 4
IT Masters: Alright, good evening everybody or depending on where you are in the world, good morning good afternoon or good night. IT Masters: Welcome to the final master class in our series of four comparative cloud master classes, led by TIM joins it masters and charleston university this week we're gonna be focusing on modern applications and microservices. IT Masters: Before we get started, and I will say that just let everybody know that there will be. IT Masters: questions answered able to be answered, about the exam at the end. IT Masters: as well. IT Masters: But as usual throughout these chats please feel free to converse with one another, there are lots of people.
IT Masters: In the chat who are extremely knowledgeable and extremely able to you know bounce ideas back and forth in the chat if you have questions for TIM about the content of. IT Masters: The master class itself, please put those in the Q amp a section on zoom if you have questions for the operational side of things, I can put those generally in the chat section. IT Masters: We have kit and Hannah once again doing admin and tech support for us, you can. IT Masters: Yes, as kid says set your chat to everybody, otherwise only the host and panelists will be able to see it. IT Masters: And you can access support from kid and Hannah throughout the week as well at learned it masters.edu.au as with the course materials, the previous recordings of webinars and any other information that you are looking for about the about the webinars and the short course series. IT Masters: As well as a little reminder just at the beginning, as well that there will be a survey about your experience with this course and that's going to be accessible as well, via it masters sorry Viola and it masters.edu.au.
IT Masters: Please do get in touch with us about the survey as well if you can't find it or anything but yeah please, please fill out that survey it's very helpful for us to improve the show courses and to improve the it masters kind of experience. IT Masters: yeah we will we'll have a little bit of a chat about the exam things towards the end as well, and in the meantime, thank you very much, everyone for attending and here is TIM Jones. IT Masters: Thank you very much. Tim Jones: Now, just to before I, before I begin on that there's been a couple of nights around the slides run the website at a week three slides so my apologies that's my error so i've. Tim Jones: sent him through to the three to the team a file, it was marked as week four but didn't actually have the week for content, so.
Tim Jones: After this i'll make sure that we get the right content onto the website so once again apologies, the correct information will be going after this until you'll have a copy of it later on tonight or tomorrow morning. Tim Jones: The right so to get into the start. Tim Jones: So. Tim Jones: First of all, we're into week for obviously.
Tim Jones: we're working through these topics tonight now one of the questions that's come up immediately, is what is the cutoff for the for the labs so. Tim Jones: Anyone who has signed up going with them, you have until the end of July, for the lab environment anyone's look. Tim Jones: Looking at this from a recorded since you have up until the end of July to sign up with us for the course and. Tim Jones: To then get access to the lab environment, but the lab environment will close down at the end of July, so you have.
Tim Jones: Several months from now, if you're live and from whenever you're coming in later, you have up until the end of July, and if you come in, after that, because you're coming into the recorded sessions. Tim Jones: You won't have access to the lab environment but but it's the type of environment, you would have if you join one of our Masters Courses or one of our other courses that are available. Tim Jones: Okay, so.
Tim Jones: going through. Tim Jones: It so we're looking first of all, at architecture in the count the idea behind tonight is to pull together a bunch of the things that we've learned over the last. Tim Jones: Three weeks and and coming into the fourth and bring it together for what it actually means for deploying applications making change and enacting new systems and capabilities in an enterprise style work workspace. Tim Jones: So the So what we have with this is a whole bunch of information that's been written by many people around what it means to architect solutions in the cloud so once the correct.
Tim Jones: file goes up onto the website you'll have the links to read all of these at your leisure, but what I thought it'd be good to go through at the moment is just a brief view of what. Tim Jones: Each of these different types of architectural frameworks or views of how we deploy applications in the cloud looks like so first of all from the aws perspective. Tim Jones: We have the design principles, the, and so what this means is this is how they suggest that you deploy your cloud based applications and cloud based infrastructure, based upon how they have as best practices for deploying those types of systems so. Tim Jones: Part of that is from from all of these systems is first of all to perform operations is code, which is what you'll see commonly across the board, from. Tim Jones: cloud providers, but also infrastructures code and modern Dev OPS or Dev psych OPS type capability for deploying into your own data Center.
Tim Jones: So one of the big advantages that you have from deploying as code is that every time you. Tim Jones: deploy something which utilizes digital assets, which is our scripts or configuration files our home charts or any other components that we have to deploy systems. Tim Jones: It means that it's the same every time it doesn't matter what systems it's it's on or anything like that it'll deploy in the same sort of manner.
Tim Jones: The rather than the normal way that we deal with monolithic applications of making massive changes at really in frequent intervals and having huge testing cycles, the view is to make frequent small reversible changes in cloud environments. Tim Jones: To. Tim Jones: refine your operations procedures on a frequent basis, and so the the capability of this is that we change as applications change and our systems requirements alter as well.
Tim Jones: anticipate failure right, so this is not only from the perspective of architecture and designing the systems of making sure that we anticipate these sort of things. Tim Jones: But to do a often paper based exercise or a whiteboard exercise with a bunch of experts to do a pre mortem, so this is something that i've been involved in a couple of times there's. Tim Jones: A whole bunch of people that are really came to do post-mortems to have what can be in some situations of finger pointing exercise to work out who's to blame for something failing. Tim Jones: But pre mortem exercises has everyone go through where something could potentially fail and working out on paper, whether that type of situation will cause a major outage and if it will happen you guys from mitigate for that or, if you do need. Tim Jones: and learn from operational failures and so every time we have something go wrong, whether it's.
Tim Jones: Security identity and access management, whether it's a failure of scripting or something else, so we want to change that and tie that back. Tim Jones: into refining the changes again so learning from our mistakes and iterating on these sort of capabilities in a very regular sort of view. Tim Jones: And all of these sort of ways of implementing cloud based applications tie back to the way that many people might now. Tim Jones: See project management and project implementation work with agile methodology so running epics and sprints and different ways of deploying new capability into organizations in a much more rapid manner. Tim Jones: So that's the aws view we've got something similar from as you're not so. Tim Jones: Here we're again designing something that's robust we've got redundancy we've got self healing.
Tim Jones: But also importantly we calling out that we want to be able to scale out our application remember there's two different ways of scaling our systems, we can scale up, which means that we add. Tim Jones: Additional processes additional Ram, and this is the old school way of dealing with application requirements so looking at a mainframe, for example, we would deploy the system and upgrade all of the components in one massive piece of iron to make the application run faster. Tim Jones: When we're asked architect in cloud based solutions as much as possible, they should be designed so they can scale out and scale up. Tim Jones: We want to partition around limits right, so what this means is if we do have limitations, we want to make sure that any workloads come into that space and not going to overload the environment that that has limitations. Tim Jones: designed for operations use managed services and use the best data store for the job or good suggestions, but. Tim Jones: One that I really like is designed for evolution so time back again to what we're looking back.
Tim Jones: At with aws of learning from our mistakes, but having a very clear view that our systems aren't static, we can build. Tim Jones: potentially the perfect architecture of cloud systems for right now for our environment, but the user base changes the application type changes the capabilities of the environments change, and so we need to keep an eye on what that means to deploying applications over time. Tim Jones: And finally, we want to build for the needs of business, so this is one of the really cool things will go into some things around.
Tim Jones: Regular business and its application architecture, a little later, but at the core our role is not to deploy technology. Tim Jones: Our role is to meet business needs that derive some value out of the technology that we deploy so the technology is all there to to meet some requirements so understanding what that is is a really key part of. Tim Jones: technical work at any level whether it's an architect, such as myself a project manager a cloud administrator or some other. Tim Jones: role within the environment understanding what the businesses looking to get out of the system gives us a perspective of what's required to deliver and making sure that that's kept in mind for all of the components that we're making. Tim Jones: From the Google perspective, so they have kind of identified so we signed off with the aws principles we've got the list of 10 from Microsoft and we've got. Tim Jones: The Google ones as well, so to start with we've got automation again that we're looking at, so we want to again automate things with digital assets.
Tim Jones: We want to be smart with State, so this is a different one from what we've had in the other, so this is looking at. Tim Jones: cloud native applications, especially when we're looking at web scale and when we're talking about web scale we're talking about. Tim Jones: applications such as instagram or Facebook, or something that's designed to be able to scale up very rapidly. Tim Jones: Now if every time someone accesses the application it expects that you're coming to exactly the same server because each server has. Tim Jones: A particular user list on there or capability or local store or something like that that's what we call state. Tim Jones: And the ideal is for as much as possible to move state elsewhere, such as last week we looked at, at no sql databases and.
Tim Jones: Putting state into no sql database or into some people might have heard of read us or some other type of in memory cache. Tim Jones: capability is the perfect sort of place to push that off to rather than have your web servers actually store information because. Tim Jones: One of the things that we want as part of that is for things like web service to be a femoral we don't want people to have to connect to the same web server each time. Tim Jones: We wanted a favor managed services, so what this means is at the back end we don't want a whole heap of.
Tim Jones: people working on every little nugget of technology and capability as much as possible, we want to push off. Tim Jones: As many tasks into the cloud service provider, because they do it really well the services are there and allows us to avoid a whole heap of work that we otherwise wouldn't make. Tim Jones: Now existing applications might make that difficult, but this allows us to for, especially for new applications to focus much more.
Tim Jones: Again on what the business needs and delivering technology for those business needs rather than technology to support the technology to support the technology to support the business needs. Tim Jones: Practice Defense in depth right so security is incredibly important whether you're deploying an application internally or deploying it to 5 million people around the world. Tim Jones: So this is where you might have heard me talk about devops right, so this is where we have cloud administrators and cloud engineers and and that sort of thing. Tim Jones: One of the things that's come slightly after that is what's termed as Dev SEC OPS right, so this is the. Tim Jones: Operation of using cloud like technology infrastructure as code of deploying using.
Tim Jones: automation but every time you're managing one of those automation or capabilities to deploy applications and systems at the very core of what everyone is doing is a view towards. Tim Jones: Security, so I mentioned before, that everyone having an understanding of what the business requirements are of what the end goal of the business of the application cities is important. Tim Jones: But having a view of making sure that each and every one of your components has a level of.
Tim Jones: Security that's suitable for the task at hand is important too, so when we're talking about Dev psych OPS it's everyone having that sort of view with their tasks, whether you're a developer, whether you're a an architect, or whether you're a cloud administrator. Tim Jones: And, similar to what we had with Microsoft always be architect, and so changes continual it's not going to stop right, so the if you're someone who wants to. Tim Jones: learn something once and then keep doing the same thing for 40 years, then you know, maybe look at being an accountant or something like that. Tim Jones: moving into the technology space, you need to keep abreast of new technologies, new capabilities and. Tim Jones: You need to understand how to implement them, but importantly, be able to view, what is important in the sense of our cloud architectures and things we're looking to deploy of what needs to be updated soon or in the next cycle something like that. Tim Jones: And we got.
Tim Jones: Another one from Google their cloud architecture framework, I went back through that that that probably is a bunch of the same sort of concepts that we've just been through. Tim Jones: we've also got. Tim Jones: Is fun see.
Tim Jones: we've got here the mule soft moving to the cloud now what the reason why i've got this here mule soft is a major. Tim Jones: API application based company, so the software and capabilities, they deliver help as develop micro services and stitching existing applications together into a whole so they help us deliver micro services application capabilities and integration with. Tim Jones: Existing or legacy type systems, now they go through a great deal of information in here, suggesting how you. Tim Jones: go through an approach it from an application standpoint, a lot of what we've looked at so far is looking at the. Tim Jones: Infrastructure nuts and bolts, but looking at the mule soft piece as a major vendor and capability is.
Tim Jones: Something which takes a different sort of view from a developer standpoint, rather than the infrastructure view. Tim Jones: Now, just as a side time you'll stop is also now owned by salesforce who are probably the biggest software as a service platform, which is in most organizations as well, so. Tim Jones: There that's a an environment that needs to be integrated with on a regular basis and managing how data is managed and integration between different applications is super important there as well. Tim Jones: And the last one here of what i'm referencing we have a look at the view from patchy court so some of you may have heard of. Tim Jones: As you caught before the the main products that i've had touch points with our Tara form and console from them, but they have a bunch of.
Tim Jones: Technology the suite of applications for assisting with deploying cloud native or modern applications and the ability to have scale out systems infrastructure as code. Tim Jones: Continuous integration and continuous deployment, so this is a good view of not only how you deploy applications in the cloud but managing. Tim Jones: The the links between existing data centers etc, so my experience there's a bunch of smaller companies that will have been able to.
Tim Jones: go directly to the cloud they'll be able to exit their data Center and go and have all of their applications in the cloud, but any of the clients that I deal with they've all still got data centers have some degree, but they're also in multiple. Tim Jones: hyper scales as well, so multiple cloud environments Just about everyone is in. Tim Jones: At least two of aws as your and JP and many of them have other cloud environments and software as a service and other capabilities that are around so. Tim Jones: The the idea of how you managed that cross cloud space and pulling information from multiple disparate sources. Tim Jones: and managing application architectures that might require pulling data from different cloud environments. Tim Jones: requires an understanding of what's happening under the hood from an infrastructure level but also having.
Tim Jones: A concept of how you can stitch those applications together using high level protocols so that's that's one of the things that actually corp and their components are really good at as well. Tim Jones: Alright, so I spoken about that a fair bit so i'll. Tim Jones: One of the other components that I think is important about this you've heard me talk about multiple. Tim Jones: clouds being the norm for large scale organizations so large enterprises have multiple clouds they've often got multiple data centers and they may have multiple systems in PO locations as well edge locations. Tim Jones: all over the place, as well as software as a service platforms, so one of the concepts which is becoming a new view of how you deploy applications is data centric architecture. Tim Jones: And what this means is that, rather than deploying H application and then working out how to link them together.
Tim Jones: You work out what the data is within your organization, how it needs to endure operate and putting some design principles around how you deploy that data or make it available. Tim Jones: So as an example i've got a colleague that's gone to work at a company called data stacks and they provide a Cassandra. Tim Jones: database so that's a no sql database, the same sort of database that the that all of the nodes the main no no sql databases from the major providers is based upon and. Tim Jones: You can deploy that in any of the clouds or in a Colocation space, which has high speed access to all of the clouds there's also from Dell technologies it's a.
Tim Jones: company that I worked for there's a product called factor, which is a large scale unstructured data repository again in a high speed cloud environment with high speed connectivity to all of the public hyper scale is so that you can have a shared repository across multiple clouds. Tim Jones: different models for how you deploy or work out your data centric architecture in some cases. Tim Jones: Being data centric might be more of a logical view of how you manage your data assets and the links between them, but it's certainly something to keep in mind, of how. Tim Jones: applications will gain access not only to the data within their own application set the links, they need to outside systems.
Tim Jones: The delays or latency that might be involved with that type of link and the long term management of that data, over time, especially when multiple applications require. Tim Jones: So, before I wanted to the next section i'll just jump over to the questions right so Questions are reasonably like so far so we've got. Tim Jones: A question from layer TIM with reference of designing a system to meet business needs what control measures can be used to maintain the same. Tim Jones: Right so bear with me i'll go through something around that in just a second, so I can live with this section or the next but i'll go through that shortly, of how we deal with the business needs and business requirements. Tim Jones: The hi TIM, can we have a copy of the hachiko White Paper, please absolutely so that's linked in the PowerPoint slides so once I hadn't through the correct version of the PowerPoint slides you'll have access to that so bear with me. IT Masters: Thank you very much, Tim and I will just answer a couple of questions that i've seen in the chat regarding the exam just a reminder that we will be discussing the exam in a little bit more detail, towards the end of the webinar but for the moment just a couple of sort of faqs.
IT Masters: If if you haven't received your invite to the aws cloud lab environment. IT Masters: The sent out weekly on Tuesdays so they are being sent in in waves so some people may not have sent may not have received them yet if you haven't yet received it. IT Masters: It may be sent next Tuesday, otherwise, please check your junk or spam or promotion folders and your email, and if you still can't locate your invitation, please send us an email at short courses at it masters.edu.au. IT Masters: And the yes, so the exam will be up towards the end of this week and we'll give you a little bit more detail, towards the end of the webinar thanks. Tim Jones: Thanks very much jack.
Tim Jones: And you see in the in the questions and so we've got a link to the hershey corp cloud operating model so it's a it's a good document. Tim Jones: Lots of interesting information another question from Leo was the most common use of cloud applications I data centric or other, so the. Tim Jones: What we continue to see overall is the deployment of systems is application centric rather than data centric there's links between applications, whether it's. Tim Jones: Using data loads into a data warehouse or into data like but it's not using live data and it's not having a data architecture which is spanning the organization so. Tim Jones: Each application often still looks like an island, so one of the things which have worked on a project with a company that you may have heard of called spunk.
Tim Jones: They they do a great deal of work, especially with things like SIS logs of security logs from multiple systems for security analysis or other analysis of things that are occurring across the network. Tim Jones: One of the use cases they have with their platform as well, because you can fit in any type of information that you have available is you can tie it in live to your application systems and use that to knit together your applications to be. Tim Jones: systems of experience for the end users and so that there's the capability to do live rearing of systems rather than waiting for data loads which might be daily or weekly or something like that and and what that means is that. Tim Jones: there's the possibility to have the democratization of data across an enterprise as well with the data centric model or a downer architecture which allows. Tim Jones: full access to what your organization is doing at any point in time, the example that I use, and that is a company like. Tim Jones: nba that might need to do track rollouts on a regular basis and there's a great deal of data from data warehouses that are available to managers.
Tim Jones: That want to run reports to see what's happening with track rollouts with weather inclement weather that might affect things or failures that happened across the. Tim Jones: The network now that's all well and good for senior managers to have that sort of information, but imagine if you can, if a. Tim Jones: User that works in one of the tracks that knows exactly what it is they do on a day to day basis and how they did it is able to query. Tim Jones: Business wide information around questions that they might have pertinent to their own personal job the insights they might be able to glean. Tim Jones: And the information that could then be used to enact change in the organization because frontline people who understand what they're doing on a day to day level at the best in the best sort of sense, are able to get access to data that would normally be completely alien to them.
Tim Jones: So question from Bruce. Tim Jones: Data centric sounds idealistic, particularly on interfacing between Apps use cases are there some good examples you know if we could look into so this really does come into the view of. Tim Jones: A of how you're looking to deploy your enterprise architecture across your network So yes, from a its idealistic from the perspective of the individual application. Tim Jones: But it's an important question of how you manage data from an application to application perspective again the democratization of data that you might have within the enterprise, but also on.
Tim Jones: How you manage that data set in the long term and so having things like xperia data of having. Tim Jones: Save times to make sure that you're you're meeting compliance requirements that having that sort of capability in an enterprise level and we're starting to see. Tim Jones: With some of the technologies that are coming out some of the new models and frameworks are available, but the capability of doing that sort of thing is sort of coming to light. Tim Jones: So cloud applications are still monolithic not necessarily so so just because an application is its.
Tim Jones: Application centric data doesn't mean that it's monolithic as well, so the two aren't synonymous, you can have a monolithic application which lends itself to being data centric. Tim Jones: Because of the way that the back end data systems are dealt with all the way that the interfaces are made available or capable of dealing with other things in a similar manner and micro services application isn't necessarily. Tim Jones: Data centric and often than not so in the most case we say applications are deployed to meet an individual business need and. Tim Jones: After that implemented the data they have inside them is found to be valuable and there's links that have been required between applications to deliver it rather than having a data architecture which the new application is eddington. Tim Jones: and find one from Leo so data centric applications. Tim Jones: More for data science functions, not just data science functions that enables data science functions and can permit you to have as the example I gave before live access to.
Tim Jones: what's happening in your organization right at this very moment, but it can also just be around the maintenance of data of the ease of integration between applications or or other functions so it's it's, not just for data science. Tim Jones: Okay, so now looking at bringing together the components. Tim Jones: Right, so this is where there's a question from Leo before around requirements so a bunch of people might see this as something familiar a bunch of people might be scared of it if they know what it is, so this is the. Tim Jones: The at the toga idea, so the, this is the architecture model for how you deliver an architecture, using the toga framework. Tim Jones: And whilst we're looking to deploy modern cloud based applications this sort of intuitive approach for how we deploy architectures and manage the architecture delivery process is still pertinent to.
Tim Jones: What we're looking to deliver into the cloud right it's a rigorous process you don't need to use all of these the individual components. Tim Jones: You use the things would make sense for your business, you can take bits and pieces out of the toga framework or use a completely different framework, but the ideal of. Tim Jones: toe gap is to provide a common sense view for how you deploy an architecture, so in this you end up with a preliminary view of what it is that you need to. Tim Jones: Do for the business, etc, the architect gets involved from having an initial brief has an idea around what things may look like. Tim Jones: And they then run through the architectural process now you'll notice in the middle we've got requirements management is part of every step of the way so that ties back to the initial.
Tim Jones: Business problem that is put in front of us, and that the requirements based upon what the business has said that they need so keeping. Tim Jones: That in mind and continuing to check each stage that we're both meeting the existing requirements that are in place, but making sure that the requirements themselves are still pertinent to i've worked on some projects that have taken many years. Tim Jones: I remember one project that I worked in.
Tim Jones: On in 1999 to to really age myself and the Someone said that that project was actually delivered in 2016 Finally, the final iteration of the project was done in 2016. Tim Jones: It had already been working for like six years before I got involved in 1999 all right so it's important, especially when you're dealing with long running projects to keep checking back to make sure the requirements are still true it's no point continuing to develop. Tim Jones: Some capability if you're developing to a requirement which the business, no longer needs right you're wasting time and an effort and you're not actually doing anything that the business actually needs at that point right so so understanding these sort of things is.
Tim Jones: As I say, toe geffen's kind of old school pretty uncool but it's still a very valuable framework for mapping out. Tim Jones: What is a good thing, a good common sense thing to do at each step of the way of how you deploy your architecture for your organization. Tim Jones: So. Tim Jones: As an aside. Tim Jones: This is a view, so this is from my from my global team within Dell that have developed this this is quite quite an eye chart. Tim Jones: The.
Tim Jones: At what this is looking at is all of the individual components that go into deploying a multi cloud capability for your organization. Tim Jones: Right and what this means is what individual components or application pieces, would you expect to see some of these things are combined. Tim Jones: or not required for our organization, but, starting from the top down if we're looking to deploy a multi cloud deployment of applications. Tim Jones: And when i'm saying multi cloud I don't just mean multi cloud is in multiple clouds but multi cloud as a noun in itself that is a way of deploying applications using infrastructure as code and those sort of devops modern capabilities. Tim Jones: So for that we need things like federated rolling user capability, we need cross crowd cloud capability and and other functions that need to sit under there, based upon whatever requirements.
Tim Jones: right down the bottom we've also got a whole bunch of infrastructure that at its base supports them so within any of the cloud service providers, you would see. Tim Jones: A selection of these things as well, so we would have software defined hypervisor as we'd have compute network storage, we have software defined infrastructure. Tim Jones: we've got insight reporting monitoring other capabilities across the board, and so, so when we're planning. Tim Jones: An infrastructure view of how we're looking to deploy something across a large scale enterprise.
Tim Jones: We want to have an understanding of how we're deploying or managing some of these functionalities right, so, as I said, you don't need all of these. Tim Jones: But you at least one to have an understanding of from an enterprise architecture view looking at your service capability within your organization. Tim Jones: You want to be able to go through each of these say, well, I needed or I don't need it and if I do need it. Tim Jones: Is it something that we've got is it something we do well, is it something that we should be changing again coming back to those presets that were looking at earlier. Tim Jones: If we need to we should re architect, we should change, we should get operational feedback and feed that back into what we're doing.
Tim Jones: And when we're talking about those feedback models again that comes back to what we're looking at with the token model of working out our architecture deploying. Tim Jones: But this is a continual cycle right, so this is reiterating what we heard from aws from as you're from Google. Tim Jones: that we need to keep architected the whole time with it's not something where we're one and done we don't create the perfect application, and then we deploy it and everyone steps away and says well that's that's great and so you need to keep on top of these things. Tim Jones: So just have a look through here jack ran the questions. IT Masters: Yes, i've got a few about toga APP So if you want to start with David asking how.
IT Masters: Do you do to gas in an agile world. Tim Jones: yeah so the I mean you have a look at the. IT Masters: tone deaf. Tim Jones: Information, so this is a it's a pretty basic view of how you run a project from an architectural perspective of creating an architecture and it's again, it looks kind of old school from a. Tim Jones: From an agile perspective from a non model application perspective but. Tim Jones: The process of creating an architecture, by its very nature, needs to in some way be a cyclical approach right, so we can't we can't follow.
Tim Jones: Normal direct agile capability for deploying an actual architecture itself is the documentation side of an architecture i'm talking about of the work that an architect does in the pre prelim to developing. Tim Jones: And an application set so you can't fail quickly right the one of the one of the really big things that you can do. Tim Jones: With architecture is spend more time upfront making sure you understand all of the components that you have as much feedback, both internally. Tim Jones: but also from external parties such as vendors from service providers from from other parties along the board and getting all that feedback and feeding that into your architectures is incredibly valuable. Tim Jones: And spending the extra time upfront right of not failing fast, which is a common ideal of.
Tim Jones: agile or quickly deploying applications capabilities in a sprint is that. Tim Jones: anytime that we spend up front saves a lot of time for all of the people that will be working off that platform so it's still maintains a iteration we still feed back into it, but there's a level of pre work that needs to be done, outside of the normal agile space, but the. Tim Jones: The actual implementation of the architecture and the work that the architect then does with the sprint teams, the epic teams within an agile methodology. Tim Jones: Is it very much works within that framework as well, so there is reasonable crossover but toga is separate from the the actual target process from the agile process itself. Tim Jones: So question from layered the toga frame.
Tim Jones: framework have. Tim Jones: lower level components reaching different operational teams to make the architecture synced with the with the design right so, so this is one of the things that we. Tim Jones: That we work on when we're creating our nation so first of all, we make sure that we.
Tim Jones: socialize the architectures with the teams that will be responsible for delivering the work right that people have an opportunity to understand it. Tim Jones: To provide feedback importantly, not only because there'll be the people that are deploying the application. Tim Jones: And that that will be the ones doing the actual work, but also because they are absolutely subject matter experts for the end of the line work that needs to be done, whether their individual.
Tim Jones: clients engineers, or any other type of specialist capability, they understand what happens right where the rubber hits the road so there's only so far that you can go as an actor so i've been an architect, for many, many years but, and I know. Tim Jones: A huge range of technologies right i've worked on mainframes i've worked on as 400 i've worked on mid range systems Linux windows whole range of database technologies i've worked with cloud service providers and and everything, and so I know a massive range of things. Tim Jones: I know it, that day, so I I don't have the experience of.
Tim Jones: Implementing technology in anger, for a very long time, not so, so no one wants to put me in front of an actual keyboard to to do any real production workloads it'd be very dangerous thing but. Tim Jones: The people who do that understand more the ramifications they deal with the change management process and their feedback is incredibly important so. Tim Jones: The the process of dealing with all of that ties in with how you deploy the architecture, but again comes back with how you work with those teams longer and longer term. Tim Jones: Question from Stephen.
Tim Jones: Quite a few circles in architecture slide. Tim Jones: The Non functional requirements ag tech architecture right, so the so technical architecture is still important, so we work backwards, first of all, we work out what it is that the. Tim Jones: First of all, what the business problems are we work at the business architecture, what the process looks like. Tim Jones: We then look at the information systems architectures that's looking at the data architecture and the application architecture from a toga perspective. Tim Jones: And once we understand what the data architecture and application architecture looks like the technology architecture flows out of that so.
Tim Jones: Each step of the way remember with coming back to the requirements management so those non functional requirements for how we deploy our technology. Tim Jones: That will fall out of the process of the business architecture, then the application architecture and the data architecture that we deploy as part of the process will. Tim Jones: define and help us find what our technical architecture actually looks like and give us those non functional requirements that help us map the systems or capabilities to what the upper level systems that we're looking at need to be deployed. Tim Jones: And question from nashville how to deploy toga toga isn't something you deploy it's it's purely a framework, a way of a methodology for deploying architectures and dealing with.
Tim Jones: Creating architectural teams and capabilities within organizations so it's more of a people in process rather than a technology discipline. Tim Jones: Right. Tim Jones: So. Tim Jones: Looking at building.
Tim Jones: microservices. Tim Jones: So, first of all, looking at micro services. Tim Jones: They first of all can be deployed independently right and allow for team or timing What this means is that we can have. Tim Jones: standalone micro services that are built completely by a team, the interfaces of well known in any application can.
Tim Jones: gain access to it, so an individual micro service can be completely standalone so you're going to have a web based API that is a single micro service that is utilized by multiple people across the web. Tim Jones: So that's a completely standard and accepted patent for deploying micro serves as an individual component now. Tim Jones: What we're talking about when we say team autonomy is, we can have different teams that are responsible for different parts of the technology we can have. Tim Jones: One team that develops in node js because they're in Belgium and that's what they developed with in that team in Belgium.
Tim Jones: We can have another component of the application another micro service which is developed out of Singapore and in Singapore, they use Python to deliver the capability, because of the data. Tim Jones: references that they need and the the framework that they need to help deliver that so. Tim Jones: With that they can have different capabilities within there but because we've got a much smaller component That brings us to the second point.
Tim Jones: Right so each of these are independently scalable so we don't require when we scale one component because it's getting. Tim Jones: A lot of traffic we don't need to scale other components, but the other side of it is we do expect that each of the components are scalable so the the architecture and design of each of our micro services should be designed with scalability. Tim Jones: Now, in some cases, it might be that one of our micro services, our components that we using is a data repository and it needs to be running on. Tim Jones: A single machine we've got backups or something like that, and for that component, we might need it to be vertically scalable rather than horizontally scalable that's. Tim Jones: that's fine, we can we can deal with that, but it really depends upon whatever requirements are for the application as a whole.
Tim Jones: We want to reduce downtime through fault isolation so. Tim Jones: So with this using micro services we we expect that the time to find any particular faults will be much bigger because. Tim Jones: we're not running we don't have components running in a complete black box, we can independently test data against individual micro services or view, where it is that particular microservices are failing either where they're requesting information or passing information back.
Tim Jones: We have a smaller code base so it's easier to understand and maintain that so again we've got a single micro services capability so. Tim Jones: we'll have a much smaller amount of code that needs to be gone through. Tim Jones: And the expectation there as well as because you've got a team that's dealing with a small paid based the team that's working on it on a day to day basis understand it really well but also, it should be well maintained and documented what each of the components do and finally. Tim Jones: Our microservices also fit well into the modern application delivery frameworks so things like cic D so it's continuous integration and continuous deployment. Tim Jones: Where you automate the process of enacting change in your environment, so you no longer have a change window that's on a Wednesday night at 10pm or something like that, where. Tim Jones: Changes are actually made it into your production environment, the expectation is because each of the micro services are atomic.
Tim Jones: they're scalable you can add individual components to the network, including updated versions of the capability, make sure that it actually works and then build up to a full deployment of the application. Tim Jones: So. Tim Jones: What about concerns what what concerns people about deploying my press services of dealing with them on time tonight. Tim Jones: So one of the big things is it's a very different type of complexity than monolithic Apps right so when we're dealing with a monolithic APP like SAP SAP.
Tim Jones: We know what it's going to do at some point we know what the failure points are or that we just need to throw heaps and heaps of hardware. Tim Jones: At the database running SAP panels and things like that we also have a wealth of people that understand the application quite deeply so for an acting change in that sort of environment there's a whole industry of people who are able to assist with that type of monolithic application. Tim Jones: With micro services when we're building up these custom application sense we have much more constrained capability to know how each of the individual components are working. Tim Jones: We could again have parts that are written in node js some that are in Java some there in Python right and so understanding the full application sick can be difficult, and this is where having. Tim Jones: A well detailed application architecture and enterprise architecture for the organization really important. Tim Jones: The other thing is the interface control is imperative if you don't have full control of the interfaces, this is the API is the way that the micro services communicate with each other or with the external world.
Tim Jones: If you don't have complete understanding of what that's doing from a higher level, then the application can break in very nasty ways, because if you have. Tim Jones: individual groups that are making ad hoc changes to the way that the interfaces work, then other parts of the application will stop working. Tim Jones: And the other thing is that it could cost more upfront depending upon what your monolithic applications or anything else looks like. Tim Jones: going through and deploying micro services, whether on Cuban 80s or function as a service or virtual machines or utilizing software as a service components, or any of those sort of things.
Tim Jones: It could be more expensive, especially if you've got a sunk cost in an existing data Center of a bunch of servants you've got the cost of migration to micro services. Tim Jones: But the actual running on a day to day basis could be more as well, it could be less and depending upon if you're building or protecting for cost less from an infrastructure perspective, then. Tim Jones: You can probably most likely do so, but it's something that that, depending upon what models are used to deploy it it's something that could come back and hit you if you were expecting to get a financial benefit immediately out of moving to micro services. Tim Jones: So how do we build right so.
Tim Jones: Building we want to have a clear understanding, first of all, the business drivers requirements again coming back to what we're talking about with toga. Tim Jones: We want to have articulation of the architectural vision and planning again coming back to that model that I was talking about before of spending as much time as possible upfront and not rushing into the deployment of the applications. Tim Jones: Is anytime that you side by finding problems in the planning phase when everything's on paper you'll save 10 times as much than what it would mean if you found it when people actually started deploying the application itself. Tim Jones: So interface points clearly mapped before any development again this comes back to adequate.
Tim Jones: understanding of what the application is, how will operate and making sure that those interfaces are mapped as part of the documentation architecture design anything else that needs to be done before starting the application work. Tim Jones: We are we have multiple Dev teams again offers often working in agile project methodology, this is just because they working in that type of team lends itself to very quick iteration cycles small teams delivering new capability very quickly. Tim Jones: And we want to have thorough and if possible automated testing of all components, as part of our microservices build. Tim Jones: So this again comes back to continuous integration and continuous deployment, that if we can finish developing something at midday, and that, where. Tim Jones: we've done our unit testing so unit testing is where developers test on their own machines, to make sure, something is working, the code can be committed at midday, and we can have automated tests run for the next 15 minutes, and we could have it deployed into production at 1230.
Tim Jones: So what technology, do we build microservices on right so again the technology should not come first, we shouldn't be building and have an idea. Tim Jones: Before we start deploying application what the technology looks like we want to have a very clear understanding of what those requirements are again. Tim Jones: Of what the business needs are what the application and data architecture looks like to make sure that anything that we're deploying or planning meets those requirements, and we should have all of those completed first.
Tim Jones: So that we can build it on themes containers server lists or sets now there's multiple ways that we can. Tim Jones: We can do this or a combination of all four of those there's no limitations to what. Tim Jones: Micro services need to be just because it's a modern web doesn't mean that we can't run it on virtual machines. Tim Jones: or cloud virtual machines or anything like that so that's that can be quite an acceptable pattern for deploying your application again it comes down to what our requirements are for running system. Tim Jones: Alright, so before we move into migrating to the cloud we've got a few more questions.
IT Masters: That we do, would you like to answer this question about which cloud based platform is most relevant to a data scientist. Tim Jones: yeah yeah so that. Tim Jones: From a data science perspective, the cloud platform that has the most weight with. Tim Jones: Data scientists and purely from a data management perspective, Google cloud seems to have carved out.
Tim Jones: A niche in that arena, not to say that you can't do similar capabilities with other platforms, but the way that. Tim Jones: The you operate and gain access to Google cloud, and some of the tools and big data sets you can operate. Tim Jones: In that lend themselves to the way that data scientists like to work so it's more of the people in process type capability as much, it is, as it is the technology or or costing or anything like that.
Tim Jones: The what else we got here so that's the question from innocent we've got one from molly So what is the best tool to implement. Tim Jones: ci CD so. Tim Jones: there's no there's no best again this comes back, we don't want to start with a view of the technology we're going to deploy. Tim Jones: To because we wanted to deploy continuous integration and continuous deployment, we should decide that first of all, a business needs continuous.
Tim Jones: Integration and continuous deployment, because they have a need for rapid deployment of new capability from a market perspective for. Tim Jones: Because of a bug fix capability, or something else, so if the business actually requires that new capability, then we should first of all, looking looking at integrating. Tim Jones: Those sort of capabilities into our application deployment process now if we've decided to do that, we can again. Tim Jones: Go back to the the architecture of how we're looking to deploy this we're pulling in all the requirements we're building out the. Tim Jones: The broader architecture and it's only when we understand how we're going to use a pen developers operate in the environment, what technology they use on a day to day basis that we can.
Tim Jones: map that back as to what continuous integration and continuous deployment looks like, but having said that, from the perspective of. Tim Jones: deploying applications and the the capabilities, the common sort of things for for doing there are applications such as Jenkins, which which provides some of the capabilities and automated testing and automatic load of new containers or other application sets you have. Tim Jones: repositories such as github, which is very common again and available to everyone to utilize for as a code repository space that again ties in with that and we've got. Tim Jones: products such as props console which can assist when we're actually deploying applications of making sure that they're. Tim Jones: registered with DNS or that our other applications can find them so there's there's a range of systems and a range of capabilities, so those those three examples that are go over a part of what we play with in the lab environments for the. Tim Jones: Micro services and virtualization course that I run that will be running later this year as an example.
Tim Jones: Question from Leo, are there any methods which can provide conversion of legacy applications to microservices types of systems, yes yeah so the so one of the key ones is the ability to. Tim Jones: migrate or convert applications into containers So if you have a small application base a small application, you can deploy that application as a container and then potentially. Tim Jones: Have it easily deployed as a scale set as an example. Tim Jones: And, and so, but that is really very dependent upon what you're doing if you've got a custom monolithic application, you really need to have a keen understanding of what's happening within each of the components now to convert some applications across it can make sense to. Tim Jones: Take piecemeal approach of individual components and what i'd term is evaporating the application, the pieces that are easy to move into micro services whether its function as a service or service.
Tim Jones: or taking components and moving them into containers you're taking part of the application across and making it available in a in a modern setting that's able to scale out and be managed in a much more. Tim Jones: Easy manner and that you can go through, and continue to update in a microservices time framework. Tim Jones: You might be left with a whole bunch of stuff which is like spaghetti code ahead so a bunch of systems that make. Tim Jones: Internal systems calls using not well known api's or hard coded IP addresses or something else there's a whole bunch of messy ways that. Tim Jones: Application developers and infrastructure people deploy applications into production environments that makes it incredibly difficult to enact any change in the future, and so. Tim Jones: For those components of a monolithic application when you have a separated the application as much as possible, taken out the easier components.
Tim Jones: That can still talk with parts of the application, but you're managing them separately, you may need to redevelop or refactor the application for the rest of it. Tim Jones: Question from anonymous you're saying that we need to have a viability business case done prior. Tim Jones: So the the viability of the business case should be done by the business so before it even. Tim Jones: comes to an architect or anything like that there should be a valid business case for why it is that we're deploying any. Tim Jones: New technology and the expectation is that there's a return on investment in some way for making change within the organization, other than things like maintenance and security. Tim Jones: And those sort of things, so the expectation is that anything that we're doing with technology should be should have some value, and that should be measurable so.
Tim Jones: The expectation is that if the business is putting forward $5 million to deploy a new application, they should be able to show. Tim Jones: The business management that the application set is going to deliver $10 million, or something like that is, that is a. Tim Jones: Normal sort of view of how these applications get up in large scale application live scaling process now the the opposite of that is that. Tim Jones: Within large scale enterprises that isn't very often at all, a process for going back and checking that applications have actually met the return on investment. Tim Jones: The the business people are able to go through and give whatever figures, they want for.
Tim Jones: A return on investment and often that doesn't come true often you have applications would sit there after spending 10s of millions of dollars that. Tim Jones: are largely unused or bringing very little value to the organization so it's Yes, they need to build a business case but it doesn't always pen through that it's a is worthwhile as it could be. Tim Jones: A question from Stephen clear understanding of business drivers requirements sounds more like waterfall than agile yes and. Tim Jones: And that's where I was saying that the architecture and the upfront methodology is not in the process of finding class you want to spend as much time as possible iterating through the. Tim Jones: The architecture and the design process and understanding what the requirements are working with.
Tim Jones: Business analysts business people with other experts, etc, and making sure that you get the design and architecture correct before anyone starts doing any actual development work. Tim Jones: So it's a it's a different process than what we would expect having sprints to. Tim Jones: Deliver individual components, we can certainly use some methods of agile methodology and architecture of having sprint's four sections or. Tim Jones: or portions or whatever, but it becomes a little bit more nebulous but also again. Tim Jones: You want to if you need to spend more time on making sure that you get the architecture and design right before you do any work whatsoever, even if it's not going to hit.
Tim Jones: A timeline or something, because the amount of savings that you will get from spending an extra week in design and architecture can save months in developing development and deployment. Tim Jones: Can we say virtual machine migration is a component of micro services provisioning so, as I said. Tim Jones: The virtual machines can absolutely be part of a microservices deployment, but again what we expect to see with microservices is that they they are atomic and scalable. Tim Jones: In and of themselves, and so we expect them, so if you've got a virtual machine that can be cloned and you can make as many copies of it as you like to sit behind a. Tim Jones: load balancer and that, if one of them disappears or a whole bunch of them disappear, then that's a virtual machine microsoft
2022-03-31 08:57
