You message someone in the same room to
A devops taxonomy helps us collate and document the many assets that are dedicated to delivering value, productivity, efficiency to the software developers, infrastructure developers, architects, system administrators and business analysts around us.
You don't put milk on bookshelves, the microwave doesn't go in the bathroom and modest bedrooms rarely have sofas.
The key pidgeon holes under consideration when grouping your tech (devops) assets are
Where clothes go shows us that state plays an important role in taxonomy. Clothes go in the
Shoes and suits are forms of clothing but they don't fit so well in some of the above pidgeon holes. Dry cleaners and boot polish come into play.
Email groups aren't that important anymore. Nobody moves e-mails anywhere (except the bin). This is because we now have powerful search and indexing tools (Google, ElasticSearch, Lucene) - so the finding part is never a problem.
Microservices tell us that grouping is not a thing of the past. The human brain does not like monoliths because there is too much to take in at once. We want our resources in bite-size, understandable and manageable chunks.
We don't group to find (in IT) we group to put, look and understand.
A group of between 4 and 7 items is excellent for the human brain. 5 methods in a class, 6 importnt web security considerations, 7 software languages to choose from, 4 candidates to select.
Our brains work best with small groupings. We don't like 200 CVs to look through - we want 5 excellent candidates and another group of 7 very good ones.
Its not about finding Joe Blogg's CV, it's about putting these CVs here and those there, then looking through, understanding and deciding.
This folder structure, philosophy and principle stands for the
architecture |-- microservices |-- patterns |-- serverless |-- restful
credentials |-- keys+certs |-- s3
cloud |-- network |-- s3 |-- iam |-- elasticsearch |-- aurora |-- redis |-- kubernetes
cmdtools |-- bash |-- search.md (grep, find) |-- network.md (netstat, ifconfig) |-- disk.md (du, df) |-- psql |-- rclone |-- kubectl |-- git |-- coreos |-- curl |-- postman |-- jq |-- openvpn |-- opensecret |-- ssh
desktop |-- firefox |-- chrome |-- openvpn |-- intellij |-- pycharm |-- emacs |-- git
devops |-- ansible |-- terraform |-- kubernetes |-- fluentd.md |-- docker |-- fluentd |-- chef |-- vagrant |-- puppet |-- cloud-formation
eco-system |-- certificates |-- iam
managed |-- circleci |-- travisci |-- confluence |-- jira |-- bitbucket |-- googledrive |-- codeship |-- github |-- dockerhub |-- kibana
middleware |-- openvpn |-- nginx |-- fluentd.md |-- sqs |-- activemq |-- rabbitmq |-- fluentd.md
stores (trumps middleware - only put things into middleware (like nginx) that aren't stores) |-- elasticsearch |-- gitlab |-- mongodb |-- mysql |-- postgres |-- memcached |-- redis |-- fluentd.md |-- zookeeper
filesystems |-- s3 |-- googledrive |-- hdfs |-- ceph |-- gluster |-- nfs |-- ebs |-- docker-volumes |-- samba
opensecret |-- use-cases
software |-- ruby |-- rubygem |-- aruba |-- cucumber |-- minitest |-- rvm |-- bundler |-- rake |-- thor |-- golang |-- gorm |-- python |-- wheels
Take time out to think about the guiding principles driving your organisation and technology. Businesses grow, technologies come and go, but your guiding principles should endure for many years at a time. I believe deeply in these IT evolution principles.
Automation is not mentioned because it is implicit in recreating everything often.
Document your goals - and the simplest way to do this is to document the patterns that are valuable in your situation. These patterns drive many millions of small changes, that eventually lead to a significant technologically unstoppable, agile business.
Patterns to consider adopting are the
The first hurdle is to being able to categorize anything and everything! Accept that they won't all fit into one bucket - unless everything has its own bucket! It must be instinctive, buckets must be mamnageable and searching needs to produce and collate the highest quality resources from the intranet, extranet and internet.
Content should never live at deeper than the third (3rd) level of a tree.
level 1a |-- level 1a2a |-- level 1a2a3a |-- level 1a2a3b |-- level 1a2a3c |-- level 1a2b |-- level 1a2b3a |-- level 1a2b3b |-- level 1a2c |-- level 1a2c3a
level 1b |-- level 1b2a |-- level 1b2a3a |-- level 1b2a3b |-- level 1b2a3c |-- level 1b2b |-- level 1b2b3a |-- level 1b2b3b |-- level 1b2c |-- level 1b2c3a
Larger apps (MySQL for example) expose many interfaces including
Certain apps, programming languages, and technologies like Python, Java and Jenkins can be eco-systems as well as clustering within other eco-systems.
A moon is related to other moons but one can cluster around Jupiter which in turns belongs to a solar system.
Apps and Platforms can eschew or implement patterns
All libraries, apps, plugins and the like implement interfaces laid down by the platform in order that searches can find and download them, installers can onboard them and their users can enjoy their offerings.
Libraries will strictly fall under the wing of a heavy-weight technology, language and/or platform.
All that is done in the name of distribution. Products, apps, and tools are distributed using libraries, package managers and platforms.
Every App (product) must
Application developers often fall foul of producing packages that are not properly placed, that do not adhere to the rules and ethos of the platform, that project an interface whose understandability and learning curve is not proportional to the problem it purports to solve, and at the final hurdle it does not deliver on its promises to player or platform.
Last edited by apollo, 2018-08-10 20:34:02