If I Can DevOps, So Can You – Part VI : “First service, the appetizer…”
By this point, your team is ready to deliver a wireframe, a mockup, a proof of concept (PoC) to see if what you want to do is even possible, in a feature incomplete way, can be done. In short, this is your “DevOps appetizer”. This can be formal, to seriously test the processes you have in place, or something quick and dirty to give your product owner or other constituents something tangible to visualize.
Having a mockup, something visual, that maps to those requirements, via user stories, in a loose format to ensure that the communication and interpretation is clear between teams, is incredibly useful. There’s plenty of visual prototyping tools, and if you have a function on your team focuses on human-centered design, they may be the user experience group, a team or individual that works on translating how people behave and think into a roadmap or set of details that software engineering teams can work from. This is also not a “one and done” activity, as your first actionable user feedback will occur at this stage and should shape, not only the product you are developing, but the method, quality and type of communications that will most likely exist during the lifespan of the current development effort.
My mockup for this site is mainly conceptual at the time of this initial writing, namely because at this point I do not know the direction of the content and features that will eventually exist here. However, that also mirrors most technology projects that encompass a major modernization and primarily new development. That’s okay, to be honest. This site will be refined and expanded as I and you, the reader see fit. Things will change during the development, deployment and long term support. It’s the nature of DevOps. I may even re-platform it in due time and maybe move it back just to see how resilient and portable things are. It’s good for you to do similar testing on such projects that require this type of flexibility, but also identified potentially hidden dependencies, and aids in documenting them and plan for any fixes or mitigations.
(insert basic diagram of publish and hosting)
The first course for this project was getting a domain name, in my case I picked a registrar, and since I’m hosting this on AWS, I setup a basic “free tier” account on AWS and started with setting up basic DNS (domain name service) capabilities via the management platform. If this is your own first personal foray into AWS’ management portal, it will seem confusing and daunting at first, because there’s a lot there, and unless you know what you are doing or looking for, it will take a moment to orient and begin the process. This will require being logged into AWS and your registrar’s control panel to update the name servers. AWS will give you four (4) DNS servers, and most registrars typically will be only prompting for two (2), but I recommend for AWS’ global load balancing to work correctly, enter in all four (4) DNS servers provided by AWS.
This will, in effect, give AWS the ability to allow you to manage host names and other aspects of DNS from their console. This is important, for when you “create” and “destroy” hosts as part of the automated deployment process, as those hosts that were last deployed were ethereal in nature. The ethereal nature is also one particular characteristic to note when you do discuss cloud security with your information security and assurance team, as the typical model for host-based/centric security tools, and especially their licensing models, typically do not handle this aspect well. There will be a need to discuss alternative methods to monitor and secure these types of hosts. The format of the discussion, plus methods and techniques on how to do so will be one of the first branching sections of this blog series.
The next steps I will be following for provisioning can be found as an implementation guide at AWS: https://aws.amazon.com/getting-started/projects/host-static-website/
The site will be static pages initially, since the content management aspects will be maintained through the automated pipelines and code management we will be building, but this is the provisioning of the target environment, and we will work backwards from there, and test integrations. This walkthrough can then be used to create more advanced features later on in its lifespan, but we will do some simple text files and graphics to demonstrate the basics.