Rayvn Manuel – DevOps 101: Getting to Minimal Viable ‘DevOps-ness’

Are you eager to get started with dev ops for your organization or agency, but you wish someone could tell you some practical advice about the dos and don'ts before you even get started? Raising Benwell with the National Museum of African-American History and Culture, part of the Smithsonian will talk to us today about dev ops, one or one getting to minimal viable dev opsness Hello, my name is Ravin Manuel and I'm from the National Museum of African-American History and Culture and welcome to my talk on getting to minimal viable devopness here at GitLab Commit Conference. And so here is our agenda, we're going to talk a little bit about myself, where I'm from, some questions to ponder and beginning this journey getting started.

Lessons learned from dev ops patterns and minimal viable def upness, which is the name of my talk. And when I was thinking about getting started and getting to an end state for developers, I minimum viable product is what you would call if you are doing and doing an application. So you go from the requirements and then you get to that minimum product where you have reached where a stakeholder can say yes or no, you have achieved it.

And that's what I was thinking of when I was considering. When you start your journey, how do you know that you've gotten to the point where you are at some place where you can measure where you've been? And so that is what minimal viable happiness is.

And at the end of this particular journey that I'm speaking with you, you'll understand what that means. So a little bit about myself and where I work. The Smithsonian Institution was established with funds from James Smithson of British scientists who left his estate to the United States to found at Washington under the name of the Smithsonian Institution and establishment for the increase and diffusion of knowledge.

The US Senate passed the act organizing the Smithsonian, and it was signed by into law by President Polk in August 1846. The Smithsonian is made up of 19 museums, 21 libraries and the National Zoo, and a number of national education and research centers, one being the Observers Observatory, our tropical research center and the education center. So that is us.

And if you've not been here to to the Smithsonian to see us other than the castle, I would suggest that you do come and visit. And while you were there, you can come to where I work. The National Museum of African-American History and Culture, which was is the only national museum devoted exclusively to the documentation of African-American history, life history, life history and culture.

We were opened our doors on September twenty fourth, twenty sixteen and was established by an act of Congress and twenty oh three took 13 years for that museum to open. And now we have more than forty thousand artifacts and over one hundred thousand members. And while you were there visiting the rest of the Smithsonian, I would totally.

Your visit there would not be complete unless you've been to our museum, and I just say that because, yes, I work at the best museum ever sorry to my peers that are at the other museums and galleries. But this is a really awesome place for you to visit to get a taste of black American history. And here is me, sworn in on January twenty seventeen, I am the senior application developer and dev ops engineer for the museum.

I work in the digital media group. I am the principal programmer for the responsible for the planning, design and implementation of some of the Web based interactive developed by the museum. I am also the DevOps team leader.

I define the standards and some of the well most of the workflows and recommend the appropriate tools that are going to be used by our development teams. I'm also there to help our leadership with the adaption or the adoption of any of our digital products. And I also administer the cloud based resources that we use in our workflow.

I also ensure that our units, our practice security practices specifically are according to what we have set up and what our enterprise it we have set up. So. When you're getting started, the first thing you need to know is your pain point, and if you don't know your pain points, then you don't know what to fix them.

And Deb ups, you have to define what it means to you. It's designed to facilitate and ease that pain of getting started. But you have to understand, does it add value?

What what does it do for you? What can you do with it? With it?

Because it's not a panacea for all. It can help with performance, but you have to think about certain things, about devops. And when you're implementing it in your workspace, does it is there somebody, some group that will that's not working as efficiently as possible?

Are there some dependencies, whether it be your workflows, your processes, your groups that are being impacted and the performance is not as high as you want them to be? Are there tools maybe out there in the cosmos that you feel that will facilitate your way of getting done? These questions, if you ponder them, they'll help you with your journey into the world and realm of them out our unit at the beginning.

In the beginning, before we get started, we are on a very strong footing. We had a very strong we have a very strong, very focused, small, well practiced teams. We are very cohesive.

And what we do and we are very well practiced, very well practiced in our agile workflow. We have a prioritized list of features and bugs in our backlog. We use a source code version control system.

We have transparency into our issue tracker. We do those scrum sprints retroactive, all of those agile things. We're very good at that.

And that is what gave us a very strong beginning in this in our particular journey. So what how did how did we get started, like what made us begin, how do we know where to begin? First, we decided to look at things that we that could address the our performance.

So that's what we decided we would do to address performance and see what things we could fix to get us to a place that we could judge and have metrics to see whether or not they were fixed. Because you can't judge if you fix something, if you don't know that it's broken and whether or not when you get there, it's not broken anymore. So we decided to look at our application workflow because we did have several challenges there.

And one was dependencies. We were dependent on several teams to get our environments up and running. And that made it so that when we had our onboarding process, it took us two to three weeks to get started from the time when they were approved to the time that we were actually able to do integration testing.

Up until that point, we lived in a very an unsustainable environment where we as developers were developing on our local developer dev environments. But we could not push them. We could push them to the repo, but we couldn't get them past the repo because we did have a development environment to actually push them to.

So our issue was our work, our onboarding. The problem was our dependency. And the and the results of those dependencies meant that it took us two to three weeks before we could get started.

So now that we knew what our issues were, we could actually address it. So documentation and incremental implementation of some fixes were how we started our journey very, very slowly, we took advantage of our cloud based resources, which we weren't really leveraging before. And because we were able to do that, we were able to just wipe away the dependency, especially when we got started.

But of course, like everything you have to document, if you don't document, then you do a disservice for yourself because you have no archival information to work off of. And you also don't have a way to look back to see what things need to be tweaked. So documentation and mental implementation are very key and getting in your journey.

One thing that so you're always learning lessons and one of the lessons learned was that commitment and commitment to change is scary. It's not something that everybody, even though everybody was on board. All the people that were needed said, yes, we wanted to do this, but the focus was on the temporary winds, the easy wins.

And even I fell into that that trap, that snare. I promised my management that, yes, we could go ahead and meet these deliverables, meet these timelines. We have these tools.

And they would really enhance our performance, which they they did the little that we automation that we actually implemented. But in the end, we had to stop. We had to pause because I found out that our work, the way we worked, even as a cohesive team, it was too brittle.

It was too fragile, because as I added more tools, added more things to our things, but more steps to our processes, it made the team slower and then it started impacting performance in a way that it did not anticipate it to impact our team. So and that was because I put too much emphasis on the tools and work flow then I did on the people and the process. So in the end, where we are right now, current state, is that we've stopped, we've actually hit pause.

And we decided that first what we need to do is look at our whole processes and find a way to fix the processes, processes to get us so that we're not as brittle in the way we work. And that is where our end state is. We're headed towards our end state.

And one thing that we're that I'm doing is I'm looking at design patterns. One of the design patterns that I'm looking at and what a design pattern is, is I've co-opted this phrase from Brett Frost, who has published the atomic design, its interactive interface design and what it's meant to do as it states here in the slides. It's a methodology, methodology to create interface design systems and a more deliberate and hierarchical manner.

And the whole point of it is to look at a business problem and to see how you can solve that business problem by creating user interfaces that are modular and that can be adapted to more to to the different devices. So it's more about how to adapt and how to be flexible in the business environment and your needs. And for this for our team, for the African-American history and culture.

Since we are not a product development team, we don't develop products for our for any customer base. We do develop interactive and we do have digital products to meet our visitors. And so what we need is a pattern that will help us to be adaptable and flexible to the needs of our visitors, but also to the needs of the stakeholders who are our curators and our educators.

They they want to get across a story and to get the story across, we need to build a digital product. But how do we get that product out there using dev ops, using the agile methodology in a way that's consistent across no matter what the digital product is, since our digital products, except for with the exception of our main website, which was one of our starting points, that's where we started with our critical app and one of the interactive apps. And we tried to find something that would meet the needs for both of those applications.

So the process to keep us from being brittle is to come up with a design pattern. So I've developed a design pattern that is adaptable, that is flexible, that will get our teams up and running, using industry best practices, using the buzzwords of tools and technologies, but in a way that's mindful to our needs. And that's what you need to think about.

You need to be able to take the debate's methodology, the pseudo religion, and make it so that it actually works for your organization. And not that your organization is trying to be adaptable and flexible to some rigid system. And so what we've come up with our dev ops design patterns and notice I don't use devsecops, because to use devsecops indicates that security needs to be pulled out and highlighted as if it's not part of already part of the process, and that is not the case.

Security is embedded in everything. So in the developers design pattern that we are looking at, that we are documenting for, our organization has two main levels, our product delivery and our product development. Those are the key foundations for the pattern above the pattern.

Since these major components and these components are embedded and included in everything, you'll see that in this image security, governance and compliance, stakeholder communication, accessibility, design, tooling and automation, testing and metrics, administration and operations and service delivery are all equally they're all equal and they're all going to be embedded. There are all things that you have to consider when you're looking at this pattern. So why the pattern?

What is this pattern supposed to do with the pattern it's supposed to do? It is supposed to give us a lens to look at our digital products when we have an onboarding of a digital product. What we're going to do is look at each of these segments and determine how much or how little of this segment plays a role.

Which security is going to always be a major segment? Because we've because it is. Because it is regardless of whether it sits in our internal host providers, what we're internally in our.

And our I can't I'm losing the word right now in our depth, our data centers, or if it sits with a cloud provider because the cloud provider does expect that their tenants are going to have some level of responsibility for security. So you'll never hear me myself say dev ops, because I think that security, along with governance, along with tootling, are just they're all as important and they all need to be embedded. So the design pattern has these knowledge domains and then it has these major components that the knowledge domains actually interlock with.

So the minimal viable devoutness for Namok, and I shouldn't say that, and I just said that I didn't mean to say that the end, which is the end goal, is that in our on boarding process, we will evaluate each project via the lens of dev ops design pattern so that we can structure an appropriate dev ops strategy and an efficient way of working to achieve these incremental and continuous efficiencies. And by doing this and by including all of those particular knowledge domains in the pattern, we should be able to document because we will come up with a plan and we will document the plan. And if we follow that plan, we should be able to meet the minimal viable dev upness for every digital project and a very consistent but continuous incremental manner.

And that is all I got for you for today. Thank you very much for joining me at our jet lab comet. And if you have any questions, feel free to put them in the chat.

And if I am online and I'm here, I will answer them for you. Thank you.