\n#\n The evolution toward DevOps\nThe \nfirst computer program\n dates back to 1843 and was an algorithm \nintended \nto calculate a sequence of \nBernoulli numbers\n. It wasn't until 1949 that both computer programs and their data were able to be stored in computer memory. It took almost a century for the hardware technology to provide a mature enough platform to effectively support computer programming. Computer hardware without software is just a bunch of electronics, whereas software without hardware is text or binary data which cannot be interpreted. They are dependent on each other to provide a usable product. This is an important distinction to make between hardware and software when it comes to \ncreating \nand \nrunning \ncomputer programs.\nWhen a software developer writes a new program, it needs to run on a piece of hardware. On a small scale, the developer can also be the person maintaining the hardware e.g. a hobbyist programmer writing some code at home.\nWhen things start to scale, let's say for a small business, the software developer can keep the few on-premise servers updated and install the new software versions every time there is an update. However, once the business grows, a single person can no longer keep the software up-to-date. Not only is the deployment process becoming increasingly complex but also when there is any kind of outage, the software developer could fall into the trap of debugging or implementing hotfixes directly on the production system. This makes deploying new changes and maintaining an operational computer system difficult, especially to repeat safely and consistently.\nIn larger organizations, \nIT operations\n were introduced to take over the deployment and maintenance aspects of the system. This gave the software developers some breathing room to focus entirely on writing and creating quality software. They would hand over new versions of the software to the IT Operations, which would then deploy and maintain the new software on the organization's infrastructure.\nThe separation of \nDevelopment \nand \nIT Operations \nwas a great answer to solving the \nscalability \nand \nmaintainability \nchallenge of an organization's IT infrastructure. However, as these systems became more complex, the separation also experienced its limitations when it came to providing a high level of \nthroughput \n(\nnew software\n) and \nstability \n(\nmean time to recover\n). Proposals to address this limitation in the form of merging development and operations methodologies already started in the late 80s to 90s and by 2009 the first DevOps conference was held.\n\n#\n The DevOps methodology\nThe \nDevOps\n methodology aims to optimize the \nsystems development life cycle\n by integrating \nsoftware development\n (Dev) and \nIT operations\n (Ops) work. \nMany enterprises, which still have IT operations and software development separated, only release new software quarterly, yearly, or even once in two years due to the significant amount of manual effort and collaboration required during such a release process. Enterprises employing DevOps principles can easily deploy new features multiple times a day.\n\n#\n The Amazon DevOps story\nLet's use Amazon's \nContinuous improvement and software automation\n story as a case study. Amazon realized that it took approximately \n14 days\n to go from idea to production (\nwhich is already fast compared to other companies\n) of which only about \n1 to 2 days\n were spent on turning the idea into peer-reviewed code. They invested in improving their Continous Integration / Continuous Delivery (\nCI/CD\n) pipeline and they achieved a staggering \n90% reduction in time\n from check-in to production. \nThe \nadoption \nof using this automated pipeline within Amazon increased when people saw the successes of the teams which were starting to use it. The adoption within diverse teams also led to various teams finding their own solutions to common problems experienced by other teams as well. Amazon learned that building knowledge messages into their \ndeployment tools\n helped share best practices with the users of these tools. This in turn enabled higher adoption of \nbest practices\n.\nAnother big lesson learned with the increased adoption was that automating a release process to increase the frequency of releases wasn't the only important performance metric. Stability was also important and mitigating the risk of introducing bugs into production required sufficient \ntesting \nat all stages of the deployment. Their CI/CD pipeline incorporated testing through the following stages:\nUnit testing\n on the build machine, including style checks, code coverage, etc.\nIntegration testing \nwhich includes automated testing with external interfaces e.g. with browsers, failure injections, security checks, etc.\nPre-production testing \nwhich tests the artifact in the operational environment. These are technical tests that verify that the service can connect to all production services, but at this point, the artifacts are not yet exposed to production inbound traffic.\nValidation in production\n means that the new software is released to only a few customers and based on validation checks may then be rolled out to all customers or rolled back.\nThese testing processes mitigate risk, but it is also important to have absolute \ncontrol \nof the actual release process. This is done through significant \nmonitoring \nof various metrics and \ncontrol options\n. The control options provide a risk barrier to moving from development to production. The \ncontrolled release\n is where the \ndevelopment cycle\n transitions to the \noperational cycle\n.\n\n#\n The DevOps cycle\nThe DevOps "infinity" cycle integrates and visualizes the Development and the IT Operations cycle. Referencing this cycle is a great way to think about this form of a systems development lifecycle. \n\nThe cycle is explained on a high level as follows:\nBased on feedback from operations one can \nplan\n for new releases. \nThe plans or ideas are converted to \ncode \nby a development team.\nThe new code is built on a \nbuild \nmachine and creates an artifact. This is also where \nunit testing\n is done.\nThe artifact is then submitted for automated \nintegration testing\n.\nAfter successful testing, the artifact can be scheduled for \nrelease \ninto the production environment using the appropriate "risk barrier" controls.\nOnce the artifact is submitted for release in the production environment. The released artifact is \ndeployed \nbased on the system's infrastructure configuration.\nThe artifact is now \noperational \nand can deliver services to its users.\nThe operational service must be \nmonitored\n. This monitoring provides IT Operations with the necessary input for feedback to the development team. The feedback is then input for the planning of new features and/or bug fixes.\nVarious tools are made specifically for each step in the process. Some even have the functionality for the entire cycle. Here is a very short list to give you an idea:\nPlan: \nJira\n, \nAsana\n\nCode: \nGit\n, \nIDEs\n\nBuild\n: \nJenkins\n, \nBamboo\n\nTest\n: \nRobot Framework\n\nRelease:\n \nJenkins\n, \nBamboo\n, \nKubernetes\n\nDeploy:\n \nKubernetes\n, \nPuppet\n, \nAnsible\n, \nChef\n\nOperate: \nDepends on your app e.g. a web server might use \nnginx\n\nMonitor:\n \nNagios\n, \nZabbix\n, \nPrometheus\n, \nGrafana\n, \nKibana\n\nYou might be thinking, I understand the DevOps \nprocess\n but at our company, we don't use most or any of the tools above and we can therefore not go "full DevOps". That is where the \nDevOps mindset\n comes in.\n\n#\n The DevOps mindset\nThere are so many companies and people using software, that it is impossible to have a one-size-fits-all approach. Newer companies/products/projects can adopt DevOps practices from the start, but:\nhow do you change your company's \nlegacy infrastructure\n and \nprocesses \nwith the ability to produce only an annual software release to a monthly, weekly, or even daily release? \nHow do you ensure \nreproducibility\n, and \nstability \nand be resilient against \nteam changes\n?\nIt starts with the development of a \nDevOps culture \nand this will certainly take time. It took Amazon almost a decade to get this right and they are still refining the process today. A way to start working on a DevOps culture is to show the \nbenefits \nto the organization, \nstart small\n and lay down \nkey principles\n such as the \nfour key principles\n employed by \nGitLab\n:\nAutomation of the software development lifecycle\nCollaboration and communication\nContinuous improvement and minimization of waste\nHyperfocus on user needs with short feedback loops.\nThe benefit of laying down key principles is that it can \nguide \nDevelopment and IT Operations teams in forming a DevOps practice that works within your organization and in your context. It is important that \narchitectural decisions\n for development and operations consider automation and prepare for a streamlined approach. In the end, it should be a team effort.\n\n#\n Summary\nSoftware needs to run on hardware, which becomes complex at scale. The evolution of maintaining the software and operational hardware systems led to the formation of separate development and IT operations teams. This dividing line between the operational systems and the development processes solved the scaling problem, but experienced challenges when it came to faster delivery of new features or bug fixes and recovery from failures. DevOps provided a solution to this by enabling scalability, faster delivery, and recovery.\nThe DevOps methodology aims to optimize the systems development life cycle by integrating software development (Dev) and IT operations (Ops) work. It focuses on:\nautomation of manual tasks, \nmitigating risk through automated testing,\nimplementing release controls, \nreproducible (configurable) infrastructure,\nand feedback loops from Ops to Dev based on the monitoring results.\nDevOps has significant advantages for an organization but ultimately needs to be adopted through the development of a DevOps mindset (culture).\nFeel free to \ncomment \nbelow or \nget in touch\n with me through the \ncontact form\n.

How did we get to DevOps?

\n#\n What is Architecture?\nThe word "\nArchitecture\n" is typically associated with the building and construction industry. The \nMerriam-Webster Dictionary\n definition of architecture states the following:\narchitecture (noun):\n the art or science of building, s\npecifically\n: the art or practice of designing and building structures and especially habitable ones\nHowever, if you scroll a bit down the architecture definition page, you'll also find the following definition:\narchitecture (noun):\n the manner in which the components of a computer or computer system are organized and integrated\nMost people outside of the \ninformation and communication technology\n (ICT) industry are only aware of the first definition. When I tell my friends and family that I'm doing "architect" work, they are usually confused, because they thought I was doing something with computers and not designing buildings. \nHowever, there are a lot of similarities between the design and construction of building structures and the design and construction of information and communication systems.\n\n#\n Why are ICT architects necessary?\nImagine you were constructing a building and you got the best electrician, plumber, builder & painter for the job and you told them to just get it done. Even though they are masters in their respective crafts, they would not be able to work independently of each other. There is always some collaboration required between them. \nYou can argue that for a small house, these experts would be able to lay the foundations, do the wiring and plumbing, paint it, and get it done through on-site teamwork. You would probably be correct, but there is one thing that this group would not be able to do by themselves, and that is: \nscale\n. They would not be able to scale this operation and build an entire development of apartments or a ten-story building with only an on-site joint effort.\n\nScalability \nis also experienced in the ICT industry. You can watch a couple of youtube videos and probably get to build your own desktop computer from ordered components at home or program something in Python. You can probably \nscale \nto doing that for a couple of friends and family. However, once you start to scale to larger business sizes, you need an architect or even a couple of architects depending on the size of the organization.\nArchitects provide ICT solutions to business problems in the same way an architect designs a building. They are individuals with the right education and experience to make design decisions for the stuff that is hard to change down the line. Usually, these designs take several months to years to get implemented by the organization \n(Much like the timeframes experienced by the construction industry).\nThere are a few different types of architects. Each of them plays a vital role in the information and communication chain. Some examples include:\n\nSoftware Architect\n\n\nSolution Architect\n\n\nSystems Architect\n\n\nEnterprise Architect\n\n\n#\n How to become an Architect\nOne of the major differences between the traditional (building) architect profession and an ICT architect, is that you cannot simply study for a bachelor's degree to become one. The road to becoming an ICT Architect is a long one \n(approximately 5-20 years of professional working experience). \nThe road usually starts with a \nbachelor's degree\n in \ncomputer science \nor\n engineering\n. This is followed by gaining experience in different areas of IT and software development, which is required to learn the competencies required for the specific architect role. \nThe next step is \nrecognition\n. Once your organization appoints you with an official title as an architect, you are recognized \nwithin \nthe organization as an architect. You can also apply for recognition outside your organization through an \nOpen Certified Architect\n (Open CA) certification. The \nOpen Group\n describes the \nOpen CA\n program as follows:\nThe program requires applicants to demonstrate skills and experience against a set of conformance requirements through written applications and peer interviews. There are no training courses to attend and no written exams to complete.\nThe Open CA program is not the only way to obtain recognition in your industry. You can also attend and participate in conferences, publish articles, and speak at user group events, in order to collaborate across various organizational boundaries. \nIn short, the title of \narchitect \nis something you need to \nearn \nthrough \npeer-reviewed, verifiable experience\n and \nskills\n.\n\n#\n Summary\nArchitects in the ICT industry focus on the art of designing and implementing software and computer systems that can scale with various interconnections, components, and business requirements. Architects think "big picture" and they provide long-term solutions to business problems that are costly to change once implemented.\nOne does not simply become an ICT architect through studying for a bachelor's degree, but one must be able to demonstrate your education, skills, and experience to your peers. The role of an architect is thus based on \nrecognition \nby the organization and the broader industry.\nFeel free to \ncomment \nbelow or \nget in touch\n with me through the \ncontact form\n.

An ICT Architect - The what, why & how

\n#\n History\nBetween the 1970s and the 1990s, there was a lot of debate between organizations, nations, and engineers to find a suitable communication protocol that would enable the best cross-boundary interconnected networking solution. This was also known as the \nprotocol wars\n.\nThe protocol wars were won by the \nInternet Protocol Suite\n (TCP/IP), which was developed by the \nInternet Engineering Task Force\n (IETF). You can read more about it in my previous \npost\n. Another big contender was the \nOpen Systems Interconnection\n (OSI) model. This model was created by the \nInternational Organization for Standardization\n (ISO). You probably have heard about some sort of ISO standard before, because the ISO standards organization develops international standards for a lot of things, spanning across various industries and countries. \nThe question is why are the other losing contenders, of the protocol wars, not so widely known/adopted by the global IT community?\nThe TCP/IP model already won the first prize for its use in the internet, but neither the TCP/IP model or the other contenders contributed what the OSI model did: The OSI model did a spectacular job of \nsimplifying networking concepts\n. This made it the standard reference model used to discuss, design and teach networking fundamentals in the classroom as well as in the workplace.\n\n#\n OSI Reference Model\nThe OSI model provides a similar \nlayered architecture\n approach as TCP/IP, but more specifically forms a basis for ISO standards for systems interconnection. It also provides additional layers, which give just enough granularity to be quite useful in explaining different stages of the network communication chain.\nThe OSI model specifies \nseven \nabstraction layers versus the \nfour \nabstraction layers specified by TCP/IP. The image below shows the layers side-by-side, grouped by function using four distinct colors. The center column also provides some examples of the types of \nprotocols \nused by each layer. This depiction highlights the fact that in using the OSI reference model, one can \ndifferentiate more \nbetween different protocols used within the \nfunctional networking\n layers.\n\nThe picture above shows mostly TCP/IP Protocols in the center column. There are quite a few OSI Protocols specified by various ISO standards, and can be seen in the table provided \nhere\n.\nAdditionally to protocols grouped by each layer, \nnetwork devices\n such as switches, routers, gateways, etc. are also generally grouped or reffered to their use by the OSI reference model layers. This also makes sense due to the fact that each network device implements a network protocol(s) in the stack.\n\n#7\n The Application Layer\nThe \napplication layer\n is a data layer which enables applications to communicate with other applications. Like the \nHTTP \nprotocol used by your browser application to display this blog post can communicate with the web server application which supports HTTP requests.\n\n#6\n The Presentation Layer\nThe \npresentation layer\n is a data layer which defines data formats. This is where encryption (e.g. \nSSL\n) and compression takes place. Your browser will, for example, encrypt the HTTP request using SSL, where the combination is commonly reffered to as \nHTTPS\n. This enables end-to-end encryption between the browser application and the web server application, which means you can safely browse the web, make requests and read responses accross the internet.\n\n#5\n The Session Layer\nThe \nsession layer\n is a data layer which establishes and terminates a \nconnection session \nbetween two different systems. This happens, for example, when you make a request, using your browser, to the web server, hosting this website. When this connection is established a network \nsocket \nis created. A \nnetwork socket\n is a combination of the underlying transport protocol (e.g. TCP), the IP address and port number. This serves as an \nendpoint \nfor sending or receiving data within a network.\n\n#4\n The Transport Layer\nThe \ntransport layer\n is a segment/datagram layer. This means it takes the data from the layers above and encapsulates it into e.g. a segment (TCP) or datagram (UDP). This is also where services such as flow control and delivery reliability plays a big role. In our browser request example, the HTTPS Protocol Data Unit (PDU) is encapsulated into a TCP segment. The transport layer will then ensure that it is received correctly and at a suitable rate of transmission between both sides of the connection.\n\n#3\n The Network Layer\nThe \nnetwork layer\n is a packet layer. This layer ensures that the segment/datagram received from the layer 4 is chopped up into packets and forwarded to the correct address using the correct and most optimal routes. This layer uses\n logical device addressing\n, e.g. using an IP address. The network layer can also decide to transmit packets through different available routes, which makes data transfers much more efficient.\n\n#2\n The Data Link Layer\nThe \ndata link layer\n encapsulates the network packets into frames. The frames are based on the specific protocol (Ethernet, Wi-Fi, etc.) used between the two physical connection nodes. This layer provides the functional basis which enables transport of a frame accross a physical medium. The data link layer is commonly divided into two \nsublayers\n:\nLogical link control\n \nsublayer (LLC)\n: This sublayer provides flow control and error detection.\nMedia access control sublayer (MAC)\n: This sublayer specifies access to the link and uses hardware device addressing (\nMAC Addresses\n).\n\n#1\n The Physical Layer\nThe \nphysical layer\n uses bits and provides a physical medium to transport data accross. It defines how cables, transmitters and receivers, send and receive \nbits \n(i.e. ones and zeros). This layer uses for example an ethernet cable \n(\nRJ45\n <-> \nUTP\n Cable <-> \nRJ45\n)\n to physically connect two ethernet supported network interface controllers (NICs) to each other. The combination in this example of "NIC-cable-NIC" comprises the physical layer.\n\n#\n Summary\nDuring the 1970s to 1990s the debate on which communication protocol stack would be the best suited for use in the internet resulted in the protocol wars. Even though the TCP/IP model was crowned victorious for use in the internet, the OSI model won the use as standard reference model in discussions, design and education of IT networks. \nThe OSI model functionally groups the vast amount of communication protocols into seven categories. These categories make it easier to design and understand complex information technology infrastructures all the way from the physical layer to the application layer.\nFeel free to \ncomment \nbelow or \nget in touch\n with me through the \ncontact form\n.

The OSI Model

\n#\n History\nAs of January 2023, approximately \n5.16 billion\n people used the internet. This is around \n64.4%\n of the global population (\nstatista.com\n), meaning that more than half of the world's population knows about the internet and uses it regularly. This computerized interconnection between people across the globe has fundamentally shaped our technological advancements and culture during the past 4 decades.\nThe origin of the internet is described on a high level as follows. The first \nwide-area packet-switched computer network\n was created by the U.S. department of defense in 1969 and was called the Advanced Research Projects Agency Network (\nARPANET\n). The ARPANET was created to enable \nresource sharing between remote computers\n. \nThe increased need for resource sharing between remote computers created a challenge on how to scale this technology. This introduced standard \ncommunication protocols\n which went through a couple of iterations until the IP/TCP protocol stack was created. The IP/TCP stack was adopted by ARPANET on the 1st of January, \n1983\n. This day is also considered the \nbirthday of the internet\n 🎉.\n\n#\n TCP/IP\nThe IP/TCP stack was further developed into a complete \ninternet protocol suite\n by \n1989\n, which laid the foundation for the internet as we know it today. The updated suite's name was also changed from IP/TCP to \nTCP/IP\n. This is based on the two most commonly used protocols in the stack, the \nTransmission Control Protocol\n and the \nInternet Protocol.\nThe internet protocol suite, or TCP/IP, basically organizes the communication protocols used in a network based on their \nfunctional \nusage. A \nprotocol \nis at its core a set of rules that specify how devices communicate with each other\n¹\n. There are numerous amounts of communications protocols due to their various usages and system interconnections required for resource sharing between remote computers. Each protocol has a particular purpose at a specific point in the communication chain. Thus, the TCP/IP framework helps us organize these protocols in logical architectural layers which address each point in the communication chain.\nThe TCP/IP framework defines four distinct abstraction layers: \nApplication Layer\nTransport Layer\nInternet Layer\nLink Layer\nThe image below shows an example of the different layers using HTTPS, TCP, IP & Ethernet protocols. A communication session starts \ndown \nthe TCP/IP stack on the left column and \nup \nthe right TCP/IP stack to request data. The response is sent back \ndown \nthe right TCP/IP stack and once again \nup \nthe left column to receive the requested data. \nGoing down the stack, the data unit passed on is wrapped with more data that hides (or encapsulates) the layer above's data. This is called \nencapsulation\n and is a fundamental concept that leads to decoupling between layers, making the TCP/IP layers robust and allowing protocols to be interchangeable on different TCP/IP stack levels.\n\n\nApplication Layer: \nYou are now using a browser to view this post. The browser uses the \nHypertext Transfer Protocol Secure\n (HTTPS) protocol to show a user end-to-end encrypted "data" like this text. The application layer prepares a Protocol Data Unit (PDU), i.e. \ndata \npacket, which is then passed on to the layer below.\nTransport Layer: \nThis communicates with the different applications above it through ports. Each application layer protocol has a specified port e.g. port 443 for HTTPS. In this way, the transport layer knows from which application layer protocol data was received and to whom it needs to forward the data. The transport layer requires a source and destination \nport \nand will encapsulate the application layer's data into a Transmission Control Protocol (TCP) \nsegment\n. The TCP segment is then passed onto the internet layer.\nInternet Layer: \nThe internet layer further encapsulates the TCP segment using an internet layer protocol such as the \nInternet Protocol\n (IP) into packets. In this layer, the source and destination IP addresses are added to the IP packets. The major advantage of breaking the data into multiple IP packets is that the packages can be transmitted \nseparately \nto the destination using the most optimal routes available for each packet. This increases the speed and reliability of delivery. The IP packets are then handed over to the Link layer for transport.\nLink Layer: \nA computer is connected to a network through a \nnetwork interface controller\n (NIC) or also known as a network interface card. Each and every \nNIC \nhas a unique \nMedia Access Control\n (MAC) address. The link layer will encapsulate the IP packets into frames depending on the type of NICs communicating with each other. For example in a wired local area network, the link layer will use an \nethernet frame\n. The ethernet frame will include the source and destination MAC addresses of the NICs in its header and also a frame check sequence (FCS) as a footer. When a NIC boundary is crossed e.g. at a router, the frame will be unencapsulated and the IP packets will be encapsulated again using the new source and destination MAC addresses for the next part of the journey.\n\n#\n Summary\nThe need for resource sharing between remote computers led to the creation of ARPANET. ARPANET was soon followed by many other networks created by other organizations. Scaling networks beyond the boundaries of companies, and countries, created the need for a standard approach to tie these communication protocols together in a standardized way. \nA layered architecture approach, incorporating all the internet protocols into one suite, was created and was also known as TCP/IP after the two most popular protocols TCP and IP. The TCP/IP framework helps us to categorize all the protocols used on the internet according to functionality. TCP/IP  was first adopted by ARPANET in 1983 and is still used today as the foundation for network design and implementation.\nFeel free to \ncomment \nbelow or \nget in touch\n with me through the \ncontact form\n.

What is the internet?

In my previous post, I explained how I stopped my previous blog ("\ncppengineer.com\n") and open-sourced it on \nGitHub\n. In this post, I'll elaborate on the architectural difference between the CppEngineer blog and this one, and how the change enabled me to host this one for free*.\nThe CppEngineer website back end used \nNodeJS\n with \nMongoDB\n to enable its \nown custom \nContent Management System\n (CMS)\n. It also used \nserver-side rendering\n with \nEJS\n templates to render the front-end static files. The rendering required a machine to host the NodeJS application.\nI used a \nDigitalOcean droplet\n to host the NodeJS application. A DigitalOcean droplet is a \nvirtual machine\n with a static \nIP address. \nYou need a static IP address to enable the linking of a DNS Entry. Thus, when you navigate to your domain name in a browser, it forwards you to a port \n(e.g. \n443\n when using SSL)\n on the virtual machine. The virtual machine then serves your website pages to the user. The cost for the droplet at the time was $6 p/m and it worked great.\nIn searching for a new modern approach for this blog, I stumbled upon the \nJAMStack\n. The JAMStack focuses on using Javascript, APIs, and Markup (JAM) as a \nweb development architecture\n pattern. This is usually produced by a static site generator or if you write your website in Vanilla HTML, JS & CSS (Thus, not using any front-end library).\nThe approach of hosting only static files opens quite a few free options. A popular one is for example using \nGitHub pages\n. I wanted to use a framework that makes rapid development possible and uses a modern approach to web development.\nAfter some research, I decided on using the \nNextJS\n framework. This framework is used by some of the world's largest companies, it uses \nbest practices\n and it can \ngenerate static files\n for my blog.\nI then needed to decide If I was going to create my own \nCMS \nagain or use a headless CMS. I decided on the latter and chose \nHyGraph\n (GraphCMS).\nIn terms of hosting, \nVercel\n makes it possible to link a GitHub account and they will build and \nhost \na \nhobby website\n for free. Vercel also provides \nserverless functions\n which allow back-end code to run on demand.\nTherefore, as a summary:\nFront end: \nServer-side rendered static files using EJS Templates \nvs. \nStatic files generated by NextJS.\nBack end: \nNodeJS, MongoDB & Custom CMS \n(Thus, running an application in the backend)\n \nvs. \nNextJS & GraphCMS \n(Which generate static files once)\nHosting: \nVirtual Machine at DigitalOcean for $6 p.m. \nvs. \nStatic generated files by NextJS at Vercel for free.\nFeel free to \ncomment \non this post or get in touch with me through the \ncontact form\n.\n\n* At the time of writing this post, I could still host this website for free\n.

How I host this blog for free

At the start of \n2020\n, I decided that I wanted to \nstart a blog\n. During that time, I was writing a significant amount of code in \nC++\n. I also had a lot of questions about how to start a website. These two factors combined, gave me the idea to write a blog about C++ (hence the name \ncppengineer.com\n). I also wanted to build it from scratch. Therefore, I specifically chose \nnot to use WordPress\n.\nMy initial focus was on how to create a front-end, and a back-end, obtain a domain and host it somewhere. In the beginning, it was quite overwhelming. This was due to the significant amount of information available on this topic, and for a while, I had suffered from analysis paralysis.\nAfter approximately \n40 - 60 hours\n of building the website, and getting it online, I started writing. I also had no idea that writing a blog post takes about \n4 - 12 hours\n. This was time-consuming and after about four blog posts, I stopped.\nI not only stopped because of the time investment but also because my day-to-day work changed. I then came to realize something I did not think of when I started: \nYour career, curiosity, and your life changes\n. It sounds quite logical, but starting a blog on a very narrow topic was therefore not the best idea in hindsight.\nAt the start of 2023, three years after starting with \nCpp::Engineer\n, I open-sourced my first blog on \nGithub\n and I've spent another \n40 hours\n creating a new blog also from scratch, but using a new tech-stack.\nThis brings me to my second \nhello world\n post on my \nnew\n blog. I now have a blog with my name as a domain \njpret.com\n. I specifically chose my own name as the domain, because it can \ngrow \nwith me and continue to give me a place which I can use for the purposes of creative writing.\nI like to write and I'm glad to have a new \nplatform \nfor me to write about things I find interesting, leave notes for myself, and share some lessons learned with others in similar domains (or even life in general).\nFeel free to \ncomment \non any post or \nget in touch\n with me through the \ncontact form\n.

How did we get to DevOps?

An ICT Architect - The what, why & how

The OSI Model

What is the internet?

How I host this blog for free

Hello World - Again 😅

Recent Posts

Categories