- Enable people to go fast
- Catch pitfalls before they happen
- Make sure people are talking
- Deadlines
- Product
- Feature
- Use Case
- Work
- Issues
- Epics
- Points
- Risk
- What is risk?
- Dependencies
- Humans
- Risk management process
- Resources
- Employees
- Systems
- Contractors
- Finances
- Budget
- CapEx
- OpEx
- Budget
- Legal
- Contract writing
- Privacy
- Security
- NDA
- MSA
- Philosophies and Methodologies - 0.5 day
- Vocabulary - 0.5 day
- Burndown
- Blocker
- Bug
- Sprint
- Velocity
- MVP
- Sandbagging
- Waste
- Retro(spective)
- Tools
- JIRA - 2 days
- Trello - 0.5 days
- Asana
- Microsoft Project
- Gannt Chart
- Developers vs management
- Context and causes are everything
- When to document, when to talk
PMP Certification - Useful for looking up learning materials
I know you know most of this at a high level, but the intricacies bite us in the ass all the time.
- Storage
- Disk
- Big
- Slow
- Fine for storing long-term things
- DO NOT use for fast stuff, i.e. things that should respond in <1s on average
- Memory
- Small
- Fucking fast
- Excellent for caching
- Goes away when the machine is off
- Use for all the fast things, but remember it's limited
- Disk
- Processing
- CPU
- Generic processing
- Generally not a huge consideration anymore
- Usually more constrained by memory
- GPU
- Super high performance for video and/or AI calculations
- Not often used in server stuff
- Expeeeensive
- CPU
- Operating System - awareness of below required, further details not required
- Windows
- Games.
- Often game servers :/
- Visual Studio, an environment for programming, is really nice
- Sucks for automation, though has been improving in recent years
- Linux
- Usually not for personal machines, except for the most hardcore of programmers or philosophical idealists
- (Almost) always free
- Based on Unix
- Generally preferred for servers, unless a super corporate environment (think SK) or game servers (in which case, you'll often find a mix of Windows and Linux)
- All of the distributions (or distros), which is another way of saying flavors, most popular are below
- Ubuntu
- based on another distro called Debian
- super user friendly
- targeting both servers and personal machines
- Red Hat
- based on another distro called Fedora
- costs money
- targets servers
- CentOS
- based on Red Hat, and therefore based on Fedora
- targets servers
- slightly more popular for servers than Ubuntu
- Ubuntu
- OS X
- Programmers
- Based on Unix, like Linux (this is why programmers)
- Servers exist... but no. Almost never used
- Windows
Most of your time here should be clearing up stuff that's unclear as written and reading up on AWS
- Hosts
- (Almost?) Always means a computer
- Can also mean someone who provides computers for servers
- Servers
- Literally, a process on a computer that receives incoming requests and serves a response (think web server)
- Often, a host can also be called a server if its sole purpose is to act as a server
- Networks
- Complicated
- Infrastructure problems that are acting like crazy voodoo magic? Blame the network, find an expensive network engineer
- Probably not often addressed when using a provider
- Providers - IaaS - Infrastructure as a Service (pay for servers rather than building your own physical data center)
- AWS - Amazon Web Services
- Provides fucktons of services on top of normal servers, including almost everything under back-end
- Make a free account and poke around after looking through back-end stuff
- Google Cloud Platform (GCP)
- I don't know shit about this
- Microsoft Azure
- I don't know shit about this
- AWS - Amazon Web Services
You'll want to do lots of supplemental reading on what's here. Check Wikipedia. Lookup common problems with each part. Lookup providers and products for each of these components. Lookup a diagram of an application "at scale" - it will use all of these and will likely help you better understand how they fit together.
- Components
- APIs
- Application Programming Interface
- Allows external programs to interface or interact with some application
- You'll often hear REST APIs, basically a style of design for APIs, worth looking up but not in extreme detail
- You'll sometimes hear RPC APIs, another style of design for APIs
- Preferred way of accessing services from outside the service
- Alternatives?
- Accessing the application's data storage directly - bad because you can fuck up the application
- Caches
- Fucking difficult
- A memory-based storage system to allow for super fast reads of data likely to be read
- Tricky because figuring out what data is likely to be read is hard
- Fortunately, is a mostly (?) solved problem
- Cache hit -> data is in the cache, so it's accessed quickly. Win
- Cache miss -> data is not in the cache, so the system needs to move to slower data storage. Loss, but fine if it's not very often. Inevitable
- Proxies
- Obfuscates what's "behind" it
- Technically, an API is a proxy, but usually a proxy is for a more explicit purpose
- Can serve the purpose of security, protocol/format translation, or scaling
- Queues
- Often only used for scaling
- Allows one or more services to consume data massively without crushing the source service
- Can be brokered (standalone) or nonbrokered (part of another app)
- Can also ensure sequential data delivery to a target rather than concurrent delivery (some databases perfer this)
- Databases
- Persistent data storage
- Stores data to disk
- Much slower than cache but should still be as fast as possible in the event of a cache miss
- Many different types and many different products per type
- Web servers
- Can be simple, static web servers like Apache or NGINX (though they can be extended into more complicated use)
- Can be custom-written
- Purpose is to serve webpages, often communicating with other back-end services to get the data needed to construct pages
- CDN - Content Delivery Network
- Stores static assets - images, videos, etc
- Often a third-party service
- Takes content from the source (usually your company'*s systems) and distributes it to their geographically dispersed hosting infrastructure for quick consumption by users
- Storage
- Storage of assets usually to be delivered to a CDN or for purposes of storing assets in a manner not widely distributed
- APIs
- Most Common Languages
- C#
- Java
- Spring
- Go
- Python
- Django
- Ruby
- Ruby on Rails (RoR) (Rails)
- Javascript
- NodeJS
- Concepts
- Scale
- To scale - to increase the capacity a service can serve
- At scale - serving metric fucktons
- Horizontal - Add more servers
- Vertical - Get a bigger server
- Horizontal almost always preferred, as there's a smaller maximum for a bigger server than there is for getting more servers
- Microservices
- Microservice architecture (MSA)
- Services should be split into tiny pieces that work together and have singular concerns
- Creates the need for service discovery and software-defined networking
- Good microservices fail dependencies gracefully - that is, if service A depends on service B, but service B is dead, service A still manages things in a manner with minimal impact
- Orchestration
- The idea of managing inrastructure in a (semi-)automated manner
- Very necessary for microservices
- Allows automagical scaling
- Logging
- Text written to somewhere for purposes of collecting information about the events within or around a service
- Often written to files
- Often log files are aggregated under a system for easy searching
- Can be used for performance analytics or for investigating issues
- Monitoring
- Answers the question: is shit broken?
- Often an afterthought, which can allow faster development but create nightmares on release
- Many, many services that allow/provide monitoring
- Scale
- HTML / CSS / Javascript
- Front-end Frameworks
- Angular
- React
- Vue
- Email - Outlook
- Chat - Slack, Skype
- Conferencing- Skype, Google Hangouts
- Wiki - Confluence, OneNote
- Documents - Google Drive, OneDrive