Forem: Kaylan Stock

What is a Coding Playlist?

Kaylan Stock — Fri, 18 Jun 2021 15:27:37 +0000

What is your favorite music to work to? OR do you prefer no music at all because you need quiet to focus on whatever it is that you are working on? Do you like music with words when you’re relaxing, but music with no words when you are trying to meet a deadline at work? At HarperDB, we have a wide range of music tastes spanning from classical, hip hop, reggae, and even as one of our devs put it: “silence with my frustrations...” 🤣. If you ever wish you had other developer’s suggestions for music to code and work to, you are not alone!

So that is why we created “HarperDB’s Coding Tunes”, a Spotify playlist with hand-picked jams from every developer on our team. We feel the pain of needing the perfect tune to have on hand when compiling your code or working through a nasty bug. No one wants to spend extra time trying to sift through the millions of playlists on your music app to find just the right vibe, so we went ahead and did it for you.

Each month we will be releasing a new coding playlist, and we will keep past months’ playlists live so if you fall in love with one you won’t have to worry about losing it. I will also be chatting with one of our fearless developers on how music moves them and posting it on our playlist landing page. With this interview, they share a bit about the music and artists that help get them through the workday. So if you haven’t already, follow the HarperDB Spotify and check out the current playlists available here.

You can also like the playlists to save them for later AND we even have an option to subscribe here if you want to know every time the newest playlist of the month has been released. Finally, if you have some coding tunes you want to submit for the next month’s playlist, you can email us at music2code2@harperdb.io. 🙂 Our entire team would love to hear your recommendations and find out what music moves YOU, our rad HarperDB community. So don’t be shy, go throw on the June playlist right now and code away!

Edge Persistence Explained (By a Non-Developer)

Kaylan Stock — Mon, 14 Jun 2021 21:58:47 +0000

Have you heard the term “edge persistence” floating around the webiverse? If so what does it mean to you? If your answer is “not sure” then this blog is for you! If you think you have an idea, let me know where you think I got it right and where I might have been off. Edge computing is the first aspect of this concept. Edge computing is the salt to cloud’s pepper. Blending edge computing with the cloud creates flexibility you would not be able to achieve with one or the other, with the added benefits of improved performance and reduced latency. So what do I mean when I say salt and pepper? They go great on dishes separately, but when combined can add the perfect finish to your cooking. Edge computing brings your computation and data storage closer to the location where you need it. It improves performance and reduces latency when running your application or technology. Now for the word persistence, I used a good old-fashioned dictionary. To be persistent is “existing for a long or longer than usual time or continuously.”

So edge persistence allows companies to globally distribute their applications, software, and technologies closer to the end-user location where it improves performance and reduce latency. When I say latency, what does that mean? Latency “is an expression of how much time it takes for a data packet to travel from one designated point to another”. It does so continuously for long periods of time.” I could end this blog here, but that wouldn’t be a very informative blog, so let’s go deeper.

The Not So History of Edge Persistence

So who was the first person to use this term? When did it become a term? Oh, and where? For what purpose? So many Qs. I am not going to lie, there wasn’t a lot of information to be found on this exact concept. Hence the header for this section. I found info on data persistence and ETL persistence, but even Wikipedia didn’t have a page for edge persistence yet. So instead I’ll focus on the history of edge computing, then we’ll add persistence to the end of edge and discuss how that came to be.

The need for edge computing was born in the early 1990s as demand for faster video and image downloads along with web pages themselves started to explode. Enter Akamai, you may have heard of them, a company that decided to create content delivery networks. This was a driving factor in the birth of what we know to be edge computing. What is a content delivery network you might ask? Akamai has a great article explaining what it means and how it works. Here is their definition (I figure its the best since, ya know, they created them), “A CDN (Content Delivery Network) is a highly-distributed platform of servers that helps minimize delays in loading web page content by reducing the physical distance between the server and the user.“

Edge computing takes the idea of CDN one step further and generalizes it. This is because CDN was created to bring the content closer to the end-user, and as we discussed earlier, edge computing brings all the datas, apps, and tech closer to the end-user. From there in 1997, Brian Noble and his team did a study that provided insights into edge computing on mobile phones. Peer-to-peer or distributed applications later came in 2001 which made apps more scalable and decentralized. I could dive further into the different types of computing like cloud and fog that developed and their deeply intertwined histories, but instead, I attached this great graphic created by the folks at bosch.io. The article that this was originally included in goes into detail about how edge and cloud computing came to be what we know today. Oh also, I just wrote an “Explained” blog on hybrid cloud so check that out as well.

Image Source: Bosch.io

So to end our history lesson for today, knowing that we understand where edge computing came from, we can put the persistence on the end and learn why we put these two things together. The need for faster applications, faster data analysis, faster content delivery, and more scalability has pushed companies to find ways to decrease application latency. This need to have hyper-fast apps that move at the speed of the Internet has exploded in the last few years and it will only continue to grow. So persistence on the edge, to me, comes more heavily into play in the late 2010s when we start to see the rise of IoT, artificial intelligence, machine learning, and the evolution of the “smart” everything in our lives. We not only need reduced latency but we need it all the time. That means all day and all night. Gone are the days when we logged onto our computers for a couple of hours or only used computers for work. So voilà, we need persistent edge computing in 2021, longer uptimes, and lower latency baby.

Who Needs Edge Persistence Anyways?

Let’s first talk about industries that need to have globally distributed edge persistence when running their tech or application. First off, I want to direct you to an excellent resource that discusses specifically industries that need a high-performing low latency database by my colleague, Margo McCabe. Here are some of the industries that really need to focus on implementing edge persistence into their products and solutions:

1.Gaming & Media- Have you ever been playing a video game and notice a small lag? You might be playing someone halfway across the globe. Did you know that there’s a big chance that even though you are here and they are in say Hong Kong that data for both of you is flowing to a single, centralized data center for the globe (possibly not near either user). Why doesn’t your data flow through a data center here and their’s in a data center there? Edge persistence can fix this through globally distributing the database used by your favorite gaming company at data centers closer to the end-user.

2. Military & Industrial- There are massive amounts of data flowing through warehouses, production lines, and delivery trucks, sometimes on a global level. Situational awareness can be driven by sensor data collection in the field, and the location can be global. If mission-critical data isn’t getting to where it needs to be on time, expensive and dangerous mistakes can follow.

3. Energy (Utilities, Oil & Gas, Mining)- When working in energy, people rely on these companies to keep the lights on while also protecting workers and those living around work sites. Data plays an important role in planning ahead. Latency can cause catastrophic mistakes that affect millions of people. The ability to make rapid decisions and execute on them in real-time is crucial.

4. Retail- Online shopping dominates the retail space and customers are demanding. A poor user experience is as simple as a user having to wait more than a second for a company’s web page to load while shopping. It’s as simple as that to turn away a large number of customers.

Why Global Edge Persistence Will Change the World

We know where the need for edge persistence has come from, and we know the history and evolution of edge computing into edge persistence. We also have some ideas of what industries and use cases would benefit from edge persistence. When I say edge persistence will change the world, I know some of you had to roll your eyes. That is a huge claim to make so let me explain. We take for granted the speed of the Internet, and the software and apps that load in milliseconds at our fingertips. The world is constantly moving at a faster pace and so will every application or software that we use. As data becomes more intricate to how we live, work, and how the world keeps moving forward, we will need these insights and decisions at faster speeds. There are also use cases as we covered above that cannot afford to have lagging speeds, downtimes, and poor performance as the consequences could be great.

With edge persistence, gone will be the days of having to skip the movie on your favorite streaming app because the show won’t load. Retail sites will load each page in less than a blink of an eye as you browse for your favorite sneakers. Production lines will be able to make smarter, faster, and more informed decisions, cutting back costs and getting products you love out even faster. Edge persistence is the future and we will start to see this term pop up a lot more frequently. We might even see a Wikipedia page for it before the year’s end. I chose to dive into edge persistence this week because here at HarperDB, we are at the forefront of edge persistence technology. We enable companies to create a unified data fabric across the globe with HarperDB distributed across a multitude of data centers, independent of the provider. A cloud independent database provides the opportunity to choose the right data center location anywhere, instead of deciding between limited centralized locations. Again, would love to hear you’re feedback on this blog, and if you have any other good resources on edge persistence send them my way!

Hybrid Cloud Explained (By a Non-Developer)

Kaylan Stock — Wed, 31 Mar 2021 16:57:50 +0000

Hello again. It’s March, and while I missed February for putting out an “Explained” blog, I have a topic today that I think could use a non-developer breakdown. Let’s just get it out there, cloud computing is a term that has been so saturated and used in so many different, confusing, and sometimes incorrect contexts, that it could be considered a buzzword and nothing more. Add hybrid in front of that and again, some of you might be doing a big eye roll at this post because hybrid cloud has ALSO become a buzzword. What do you think hybrid cloud means? Can you summarize it in one or two sentences? Hybrid cloud is a blend of public and private (on-premise) cloud. Boom- article done? Not quite. Read on for a deeper look into the equivocal term, hybrid cloud.

Prerequisite: Cloud Types

Stratus, Cumulus, Nimbostratus oh my! No, no, I know we aren’t talking about those cloud types. Although I will note my favorite type of cloud would have to be the Kelvin-Helmholtz.

Image Source: https://scied.ucar.edu/image/kelvin-helmholtz-clouds

So just like the clouds in the sky, there are different types of cloud computing. I’ll start us out with some easy-to-read bullets:

Public Cloud- So much space for activities! Public cloud is great for general purpose use cases or ones that require a lot of space for storage without a crazy high cost.
Private Cloud- Usually operated by the company that is using it, private cloud can also be known as on-premise (on-prem, for short) and is fully managed by the provider/company for singular use. On-prem arguably has a higher capability to be more secure (if you have the right DevOps/Security folks) because, well, it’s private and no one else has access.
Hybrid Cloud- The combination of private and public cloud, kinda like a Limequat, a combination of lime and kumquat. It's two great products put together to make something that satisfies two types of taste buds, or in hybrid cloud’s case, cloud buds 😆 We’ll go deeper on hybrid cloud later because this blog is after all about…hybrid cloud.
Community Cloud- Think cloud, but make it a neighborhood watch. A group of organizations with similar product offerings or in similar industries come together and share an infrastructure that can be either internally managed or managed by a 3rd party. It’s a cloud block party!

Then there are different types of services that you can find in Cloud Computing:

Infrastructure as a Service (IaaS)- An example would be AWS or Microsoft Azure
Software as a Service (SaaS)- An example we all know (and love / sometimes hate) is Slack (does anyone else have nightmares about the Slack ping?)
Platform as a Service (PaaS)- Examples include Heroku or Elastic Beanstalk
Function as a Service (FaaS)- All the big-time folks like AWS, Microsoft, etc. have function as a service. A function as a service in short is serverless as a service IMO. You can define a task(function) without building infrastructure which can be a huge, costly, time lengthy job.
Database as a Service (DBaaS)- Umm hello! HarperDB has a DBaaS offering!

Whoa, that’s a lot of acronyms! Cloud companies provide these packages or service models so that you can select what works for your use case or business model with minimal work on your end to get up and running. “As a Service” means your cloud provider is like your cloud waiter. They work with their team to provide you a clean table, delish meal, and clean up after you leave. Only for cloud computing that means they handle the infrastructure, the support, and make cloud computing so tidy that you might forget about all that is happening in the background.

The History of Hybrid Cloud (Short & Sweet)

When I was doing my research for this blog, and this particular section, the first article I found was titled “The Ironic History of Hybrid Cloud.” If that doesn’t spark your interest in a history lesson, I don’t know what will! While cloud computing seems like a fairly new concept (by new I mean the 2000s), it actually dates back to the 1960s which blows my mind! A book called “Intergalactic Computer Network” by Joseph Carl Robnett Licklider helped create the idea that is cloud computing as we know it today. Enter Salesforce in 1999, where cloud computing becomes an actual thing that people could use, and then we see AWS emerge in 2003 and the rest is history.

As with all good things, they usually have a downside and cloud computing was no different. Developers in larger companies were finding it harder and harder to achieve their goals with costly, time-consuming private cloud implementations. They started to use a back door option that meant skipping around their IT department and using cloud providers like AWS or managed software like Salesforce, to implement their use cases at half the cost and in half the time. The problem with this was it was breaking protocols around security, and to be fair, simply wasn’t as secure as on-prem practices. This is how we come to meet hybrid cloud. The best of both worlds: security and ownership from on-prem with the flexibility, cost savings, and endless opportunities of public cloud.

Hybrid Cloud v. Multi-cloud

First, the nitty-gritty of what a hybrid cloud is. As you know, I love pulling from past blogs from my fellow HarperDB teammates, and this is no exception. Kyle, our CTO, calls hybrid cloud the “peanut butter to your chocolate” and you know I love a good food reference. Hybrid cloud is a combination of at least one private and one public cloud. The multiple clouds are managed by a managed service, container, API, or even a data lake! You can either connect the clouds themselves or focus on making apps that run inside each cloud portable so that they can be shifted from one to the other quickly and easily. You can really build out any blend of technologies to free up your dev and IT teams using hybrid cloud, the possibilities are endless. One example would be a development team that runs applications across both private and public clouds for redundancy and they put different software in different places for security.

Hybrid cloud is great for disaster recovery. This means that an IT team or dev team can create an exact replica of their on-prem cloud in the public cloud for failover and backup. Hybrid cloud can also be used for application development and testing environments. Public cloud is great because it's quick to get up and running, super-fast, and also easy to use, but when it comes time to deploy a lot of companies want the security of on-prem for production data. Hybrid cloud allows you to shift between the two. A third application of hybrid cloud goes by the term “cloud bursting.” This is when companies use public cloud for overflow of data in times of high activity. Think of a social media company that might monitor Tweets for a client, but when the client has a big event and they have more than normal amount of tweets coming in, cloud bursting could be used for the higher volume of Tweets they need to monitor during that event. Finally, a fourth use case might be when a company has mixed data sets that they are working with and analyzing. For example, say that same social media company has a healthcare client whose social data, for some reason, falls under HIPAA requirements or maybe they have a Europe-based client that needs to follow GDPR. They probably want to store that data in a secure private cloud while the event client’s tweets can be stored in the public cloud.

Enter multi-cloud. Multi-cloud is two or more public clouds or private clouds, or a combination of many public and private clouds. Basically, it’s a lot of clouds ☁️ ☁️ ☁️ ☁️ . Multi-cloud means that these public, private, or hybrid clouds are connected in some way. Multi-cloud usually means an organization has very specific use cases for their different types of clouds. They also may use this strategy to minimize downtime, data loss, and create more storage for their organization.

Example of Hybrid Cloud Architecture using HarperDB

What Do You Think?

What type of cloud model do you use for your projects or at your company? What is the best option in your opinion, and do you have a cloud provider you are a fanboy/fangirl/fanperson of? I love to hear from you so let me know! HarperDB (of course!) has my vote as the best hybrid cloud solution, but we all know I am biased 😉 We are constantly rolling out new features and functionality that make the product ideal for low latency, high-performance data ingest, and data analytics.

I’m always taking topic suggestions, you can DM me on Twitter with your ideas or feedback if commenting isn’t your thing: @kaylanne04!

Geo-Distributed Data Lakes Explained (By a Non-Developer)

Kaylan Stock — Wed, 27 Jan 2021 17:57:08 +0000

Happy 2021! This week’s term is a mouthful, but don’t let the long name deter you. It’s a pretty interesting topic and I think you will agree after finishing this breakdown. There is a lot to say about how awesome it is to combine the flexibility of a data lake with the power of a distributed architecture, but I’ll get more into the benefits of both as a joint solution later. To start, I want to look at geo-distributed data lakes in two parts before we marry them together, for my non-developer brain that made the most sense! No time to waste, let’s kick things off with the one and only… data lakes.

It’s a Data LAKE, Not Warehouse!

It shouldn’t be a shock to the system to point out that we are living in a data-driven world going into 2021. Because of this, “data lakes” are a fitting term for the amount of data companies are collecting. In my opinion, we could probably start calling them data oceans, expansive and seemingly never-ending. So what is a data lake exactly? Think of all your data as the water and your repository as the lake that holds that water. Unstructured data or “water” comes from one source and your structured data/water comes from another. You can use any of the water coming from any number of water sources (i.e. multiple structured and unstructured data sources) to build out visualizations, real-time analytics, or even machine learning models. So while your water is flowing in from rivers, creeks, and mountain runoffs, you can drink any of that water and it will keep you hydrated.

Data lakes can be on-premise or hosted in the cloud, and I think my favorite thing about data lakes is that the natural or raw form of the data that is stored in a lake is usually called an “object blob.” What is the first thing you think of when you hear the word blob? It’s such a great word. So thanks to object blobs in data lakes, data management becomes more cost-effective than other solutions when it comes to storing historical data because it allows you to store both relational and non-relational data. Data lakes democratize data, which simply means that everyone has access to the data instead of having gatekeepers or admins that decide who has access. Data lakes also provide folks with an easy way to understand said data that is shared in the data repository. I can imagine at large companies with many employees and departments, a data lake makes company collaboration ten times easier.

There is a difference between a data lake and a data warehouse, which should be mentioned before we move on. According to AWS’s website, a data warehouse is a repository database optimized for specific data used to analyze relational data coming from transactional systems and line of business applications. So that means data warehouses do not handle unstructured data or are not optimized to handle it. So I say, in 2021 with hundreds of data sources, all hail the data lake!

Geo-Distributed: Data All Over the World

In general, geo-distributed is used in reference to data storage, websites, applications, containers, etc. For the sake of this article, we will focus on geo-distributed data storage. A one-sentence description of geo-distributed databases and storage would tell you that it means a database technology deployed across more than one geographical location without performance delays. Some might say that geo-distributed data storage can come in the form of zone, region, or even multi-cloud.

Multi or Hybrid cloud is an important architecture in this case because it's a powerful and cost-saving example of geo-distributed. To quote our very own CTO Kyle “Hybrid cloud is the peanut butter in your chocolate, it can be an intermixing of public cloud services, but is more typically a blend of private cloud (or on-premise) with public.” When working with hybrid cloud, you are using multiple local "edge" nodes closer to the end-user, instead of large centralized data centers, hence to implement hybrid cloud you are using a geo-distributed data storage architecture.

Geo-distributed functionality is great in the sense that with the increased redundancy, you don’t need to worry as much about one data center, cloud instance, or on-premise site going down. A fail in one location isn’t the end all be all for your team, data is gold after-all. Global performance is improved because queries are distributed across many different servers in parallel, and users are able to hit a database that is physically closer to them, ultimately reducing latency (or if you want to be fancy you can call it “interquery and intraquery parallelism”). The user experience is also better when data storage is distributed because of the rapid query times.

Mix Them Together: Hello Geo-Distributed Data Lake!

So we have all the ingredients, now let’s bake this data cake! From here it’s pretty easy to understand that a geo-distributed data lake is a type of geo-distributed data storage. A data lake distributed across multiple locations….kinda sounds like the data version of an ocean! As a powerful way to collaborate efficiently with large dispersed teams, geo-distributed data lakes make big data analysis easy and user-friendly. Companies spread across the country or even the world can easily access company data and know that the data they are looking at is the most up to date version, which comes in handy, especially when dealing with real-time mission-critical analytics. Here's a nice bulleted list for all my dev friends on the advantages of a distributed data lake (hint: I touched on some of them when talking about geo-distributed data storage):

Collaboration and Synchronization- These two things can become streamlined and done in real-time when you have multiple copies of a database out in the world. Local teams can have the data most important to them running nearby, making it easy to pull the most recent updates.
Data Redundancy and Recovery- Similar to when we talk about general-purpose distributed data storage, you don’t have to worry about network, data center, or any other outages or downtime. You have backup from your other replicated data lakes there to give you peace of mind.
Performance- Instead of one large data lake, you now have many smaller data lakes spread across your network (also known as load distribution). You aren’t hammering one system all at once.
Agile Development and Data Analytics- Distributed data lake means you can use the same data across different applications along with improved collaboration and sync, as listed above. Your team can work in a smarter and faster fashion.
Scalability- It's easier to scale your data collection when you not only have the flexibility of a data lake that can collect both unstructured and structured data, but you also have access to multiple copies of that data lake spread across different locations. With a distributed architecture, you can easily add additional data lake nodes as demand increases.
Cost Savings- If you are using the hybrid cloud model that we discussed earlier, then you can significantly cut the costs of your data lake. This is because you are not exclusively locked into cloud providers and their cloud hosting costs, instead, you using localized edge nodes that are maintained by your organization or a third-party.

Use Cases & Tools for Geo-Distributed Data Lakes

With so many benefits to geo-distributed data lakes, use cases and tools that work in the geo-distributed data lake space are not hard to find. Here are some of my favorite ideas for implementing distributed data lakes:

Internet of Things (IoT)- A no-brainer. IoT data can be a pain in the…. and a lot of IoT use cases require real-time or near real-time analytics. When you combine the ability to pull in large amounts of structured and unstructured data with the replication of a geo-distributed architecture, you get the perfect IoT tool. Now your IoT strategy and implementation won’t get bogged down by how to store the massive amounts of data coming in from many devices across many locations.
Extract Transform Load (ETL)- Data lakes are famous for being an excellent route when working in ETL and this is because you can now extract and load your data into your data lake and transform it whenever you need. Imagine the power of this strategy being multiplied across different locations.
Enterprise and Big Datad- This makes total sense when you consider the benefits above, including agile development, data analytics, scalability, collaboration, and data sync.
Advanced and Real-Time Analytics- When you aren’t worried about the operational side of your data storage, you can focus on the juicy part of data collection, analyzing, and putting your data to work!

With these use cases in mind let's talk tools. HarperDB works for all of the above use cases because it can ingest both structured and unstructured data. That allows it to act as a data lake repository. THEN add in the advanced clustering and replication capabilities, followed up with SQL capabilities for analytical jobs and you are not only working with a geo-distributed data lake, but you can also use HarperDB simultaneously as a data warehouse! You can spin up HarperDB on any computing device, from large scale servers down to micro-computing devices like the Raspberry Pi. Other great tools to check out for geo-distributed data lakes include Snowflake, Cloudera, and Databricks, which I have linked to their Data Lake info pages if you are curious about how they all fit into the landscape. “Distributed” is becoming quite the buzzword for good reason, and it will be exciting to see how that space transforms as more and more teams adopt a distributed architecture.

Combining the flexibility of data lakes with the power of a distributed architecture is a no brainer in my opinion. Data lakes provide an easy way to ingest all types of data, store large amounts of historical data, and then use only the data that you need when you need it. Geo-distributed enables improved performance, cost savings, scalability, and better safety nets for the ever-growing data needs of modern-day enterprises and startups alike. As always, let me know what I missed and shoot me your ideas for my next “Explained By” blog. 👋

Containers Explained (By a Non-Developer)

Kaylan Stock — Mon, 21 Dec 2020 17:49:14 +0000

Happy Holidays! I wanted to squeeze in one more explained blog before the end of the year and I picked a doozy to finish out 2020. Let’s take a look at the mysterious, the elusive, yet amazing THING that is containers (yup, calling it a thing). When I thought about containers before I did my research, my first thought was Docker and their cute blue whale. I thought of a Tupperware container with a few carved out sections (think bento box) that has different types of food in each section, and when you open that Tupperware and eat all the food, you get a cohesive meal that works together to power the person eating it. Are you ready for your lunch break now?

Containers History

So did anyone else think containers were relatively new or was that just me? Welp, news flash, they are older than we all thought! I did find an article dating them all the way back to 1979 when Unix V7 came along. Unix V7 allowed users to use the chroot system call which meant that they would find the root directory of a process to a new location in the filesystem. So, process isolation is a simple and effective way to isolate a process, a core component of what would become containerization. Examples of process isolation can be: Preventing process A from accessing the memory used by process B, and preventing process B from opening a file that process A has opened. So Process A and B can never be together… and now I feel like I’m writing the next Romeo and Juliet story here.

In 2000, the tech world was booming. It was young, but finding its footing on a pathway to greatness. Some of you may know this time as the “dot-com boom. The first implementation of containers became available in a new FreeBSD mechanism called jails. Jails had three goals including virtualization, security, and ease of delegation. Ease of delegation in this case means the ability for system admins to assign and delegate several tasks which require superuser access without handing out complete control over the system. Virtualization means that each jail is a virtual environment running on the host machine with its own files, processes, user, and superuser accounts segregating each environment so they are completely isolated from each other.. From within a jailed process, the environment is almost indistinguishable from a real system.” That is a direct quote from the jails Wikipedia.

By 2001, a version of containers was available on Linux via the VServer project. This was created by Jacques Gélinas, and the solution allowed users to run multiple Linux servers on a single box while maintaining security and independence. From there, containers incrementally got better and better, and a wider variety of products hopped onto market such as Solaris Containers, OpenVZ, Process Containers, LXC, Warden, and Let Me Contain That For You (love this name!). In 2013, the one and only little blue whale appeared in the market, and Docker has been the dominant container company ever since. If you want to know a bit more about the listed technologies, you can check them out here in this nicely written summary.

What is a Container Anyway?

So who should I turn to in order to better understand the mysterious technology that is a container? Docker of course! My initial description of containers wasn’t completely off base. Docker calls container software a package, and I personally like my bento box analogy better, but I am what some may call a “foodie” so I understand things better when they’re described in food terms. Here is Docker’s definition:

“A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another.”

Image Source: https://www.docker.com/resources/what-container

Let’s break this definition down. Unit of software in this case means that the container is one technology, one singular THING. Oops, I used thing again. The way I see it is that while some applications can have multiple aspects to them, containers do not. This becomes more relevant when we add packages up code and all its dependencies. So back to my bento box analogy. The container is a single dish. The application is built using multiple containers interacting together, just like a bento box is built from multiple dishes. The difference from my initial stab at containers is that it’s not really about the food in the bento box, it’s that when you have your food in the box, you can take it with you easily to wherever you want. It’s also about making sure the food doesn’t touch… You don’t want your soup mixed in with your rice.

Containers hold everything needed to make your application run in an isolated environment so that you can take the app across different computing environments with ease. What’s faster? Taking your food, packaging it up, and then unpacking it onto a new plate at the next location… or putting your food in your bento box and leaving it organized in that container everywhere you go. Okay now my bento box analogy is starting to REACCHHH, but hey I’m rolling with it.

Let me also break down what Docker’s definition means by computing environment. When a problem is solved by the computer, that computer uses many devices while solving that problem, arranged in a multitude of ways and which work together to solve the problem. These devices make up your environment. You may use a personal environment on your laptop, but have a different environment for your work computer, and then maybe a different one for the client you are coding the app for. A common environment that you probably use in personal or work projects is a “stage” environment and “production” or “prod” environment. A production environment is where your code runs to make your application/software/product work where as your stage environment is where you write and test your code to make sure it works for prod. Other types of computing environments include, but aren’t limited to: distributed computing, cloud computing, and cluster computing environments.

So your computing environments can be considered in relation to our bento box analogy as say your home, your job, your gym (if you eat food at your gym? lol), maybe you go to night school. You can take your nice little organized bento box and eat your snacks more efficiently and easily. It's more reliable to carry all your snacks in one box and more secure. You’re less likely to lose snacks along the way when they are all in your bento box. Do you like my bento box analogy? Lmk in the comments! I’ll leave you with a nice bulleted list of the benefits of containers:

Agile Development- Containers mean you can be more agile, and are you even a developer if you don’t follow agile practices?
Containers=portability- Its so much easier to deploy to different computing environments when you have your bento box!
Efficiency- You can work smarter and get more done when you implement containers because you can trust that your code is going to work (hallelujah).
Consistency and Reliability- this goes hand in hand with efficiency. Let’s break down an example on how containers provide this. A Docker container is guaranteed to run with identical behavior regardless of where it’s installed. For example, the HarperDB container works on Docker on Linux, Mac, and Windows. So even though you can’t install HarperDB on Windows, you can install HarperDB’s container on Docker for Windows and get consistent behavior.
Less Overhead than Virtual Machines- taking it back to my bento box one more time. You need LESS stuff if you eat from your bento box all day. Your bento box could even have a nice little sustainable fork and knife (yay being green!), so you don’t need to find a new set of silverware everywhere you go, you don’t need a new plate, etc. etc. Virtual Machines would be another great explained blog at some point in the future, here is breakdown by none other than….Docker!

How and What to Contain with Containers

So we know what containers are and the history of where they came from, but what do you use them for? Well, I mentioned probably one of the most common use cases above briefly when I talked about stage vs. prod environments. Why do development teams use stage v. prod? Well, why do we write blogs in our notes/word/google docs before we post them? You can think of the stage environment as the draft of your code. You don’t want to throw code into prod and then break your entire product which real live customers are using unless you’re pulling a Jared Dunn from Silicon Valley and paying people across the globe at click farms to up your active daily users. 🙂 So stage is the place where you are free to f*** up, test your code, and make it rock.

Another use case for containers is to modernize your organization’s applications by way of the “Lift and Shift” method. You can move your applications into the cloud when you containerize them. You can also use containers to better support your microservice architectures. If you containerize your different individual microservices, you then have building blocks that allow you to deploy and scale those microservices like a pro.

One last example (although the possibilities for containers are endless) is to containerize your machine learning (ML) model. It’s a big challenge to deploy ML models in prod that can scale, and containers allow you to do that by distributing the ML application by spinning up multiple containers across multiple machines! Then you can utilize orchestration with tools like Kubernetes to easily manage all your different ML containers. Orchestration is the salt to container’s pepper. I probably should do an “Orchestration of Containers Explained” blog in the near future because that’s a whole other beast.

Cool Container Conclusion

Yup, it’s cool, it’s about containers, and it’s a conclusion. Wow, lots to unpack when it comes to containers. This blog in no way explains everything surrounding containers, but hopefully it helped clarify some basics surrounding this amazing software. Zach recently wrote this epic blog about HarperDB’s containerization journey and I think it's a nice follow up to this blog if you want to keep digging and learning about containers in a real world example. Also, I do have to plug the HarperDB Container on Docker Hub. Docker makes it easy to explore and develop on HarperDB. After Docker is installed, it’s a simple command to get up and running on HarperDB in your local environment. Docker abstracts the process of installing and configuring HarperDB, so developers can iterate quickly with a new or existing HarperDB datastore.

Finally, Happy Holidays and Happy New Year ya filthy animals!

WebSocket Explained (By a Non-Developer)

Kaylan Stock — Thu, 03 Dec 2020 17:11:21 +0000

Welcome back! It’s been a minute since I explained something most of you probably know better than me 🙂. For WebSocket, I knew very little before I did my research. I understood that it was widely used and that it was a tool for two way communication, but had no knowledge beyond that. So let’s get right to it!

The Evolution of the WebSocket

History time! What came before WebSocket? HTTP of course! HTTP is a stateless request-response mechanism that stands for “hypertext transfer protocol” and it worked well for many years and is still a great option for certain use cases today, think websites, HTTP is a great fit for this use case. The request/response mechanism was basically used for the same thing WebSocket is used for today, albeit some use cases have far outgrown HTTP. If the connection dropped between the request/response with HTTP, it wasn’t a problem. You could restore communication at any point thanks to its stateless nature. Back in the olden days, there was only a need for dealing with text docs and a limited amount of additional assets, so HTTP was all that was needed.

Evolution is inevitable when it comes to the world of tech, and applications quickly evolved beyond what HTTP could offer. Developers needed more because applications were shifting towards real-time implementations, and latency from the high frequency of request/response was making it impossible to achieve the real-time communication needed. Thus came long polling which allowed the TCP connection to stay a little longer than HTTP, but this was really just a temporary bandaid rather than a full solution. There were still issues with latency and overhead… so Hello World, WebSockets were born!

Before WebSocket was called WebSocket it was referenced as TCPConnection in the HTML5 specification, as a placeholder for a TCP-based socket API. WebSocket came to be in June of 2008 when Micheal Carter, a tech entrepreneur, led discussions around the protocol that would become WebSocket. What’s behind the name? Carter and a fellow by the name Ian Hickerson coined WebSocket in a chat room. One could even say they named the two way communication protocol using a two way communication tool (see what I did there)! By the end of 2009, Google shipped full support for WebSocket with their Chrome 4 release and it became widely available through multiple browsers by 2011. Even iOS and Android support WebSocket as of 2013, so there are really endless possibilities when using the protocol.

WebSocket: To Transport or To Protocol

So now that we have the history, let’s break down the technology. WebSocket opens a bi-directional communication path between a server and client. This path is persistent which is a fancy way to say continuous and in both directions, so there is very low latency and high efficiency within the communication path. You don’t have to worry about individual responses and requests, instead it’s like the infinite loop that is always on as long as parties have agreed to an initial “handshake” (which is actually a response/request HTTP call, meaning there is a touch of old school thrown in with the new).

One article I found described WebSocket as a thin transport layer built on top of a TCP/IP stack. They also mentioned that some refer to WebSocket as a protocol (i.e. me) while some refer to it as a transport. The author says transport is more accurate and I actually found this very interesting because I never had heard it called a transport before and will call it a transport going forward in my blog. I don’t want to divulge too much into this argument, but take a read for yourself and then let me know what sounds more accurate to you in the comments! Side note: if you want a really in depth read from someone with a technical background on WebSocket, this article is overall an excellent resource and I found it to be the most in-depth resource out there.

Image Source: https://hackernoon.com/everything-you-ever-wanted-to-know-about-websockets-literally-a05f36432999

There are three main interfaces when it comes to WebSocket:

WebSocket-primary interface for the connection of the server to send/receive messages
CloseEvent-event when a WebSocket connection closes
MessageEvent-event when a message is received from the server

WebSocket has provided a standardized way for client applications and browsers to talk to servers without tedious requests every time. Work smarter not harder is what I always say and WebSocket lives by this code!

WebSocket Use Cases

The main purpose of WebSockets has already been stated: a communication path from your application to your server. Here are some more specific ideas for using WebSockets that follow the server to app path:

Social feeds, news feeds, and chat rooms!
Games that are for multiplayer
Collaboration tools like Dropbox or tools for collaborative coding
Location based apps (hello Find My Friends- is this stalker status or cool? Thoughts?)
E-learning- well that seems relevant in 2020!
Many others! Anything you can think of that I missed?

Data visualization is another use case for WebSockets, again due to the real-time nature that can be needed for data visualizations, like say, for maps that show real-time weather data so that you always know whether to rock your flip flops or your snow boots (if you live in Colorado like me then you wear flip flops regardless because we are hardcore here)!

Review WebSockets with Actual Developers 🙂

Next week, the HarperDB team is putting on one final virtual event to close out 2020. If you want to go deeper into WebSocket and what it can do for you, you should RSVP! We will be joined by Casne Systems Engineer, Carl Argabright, to chat about all things WebSocket and explore a case study using WebSocket as the fastest method for collecting high resolution data for analytics. The event will be on December 8th (that’s only FIVE days away!) at 5:00pm PST. (No worries if you can’t make it live, if you RSVP you’ll receive a recording of the event afterwards!)

If you prefer written tutorials and content, Ethan Arrowood just wrote this excellent tutorial on HarperDB and WebSocket. You can check out the HarperDB WebSocket Client in the HarperDB Developer Marketplace. As always, send me feedback and tell me what I missed when it comes to the wonderful world of WebSocket. Or if you have suggestions for what I should cover next in this series please LMK!

Python Explained (By a Non-Developer)

Kaylan Stock — Thu, 15 Oct 2020 15:00:24 +0000

Another week, another “Explained By a Non-Developer” blog! Are you tired of ‘em yet? This round is dedicated to another cult favorite programming language, Python. Before I did any research on Python these are the things I could tell you about it (or at least things I thought I knew):

It’s loved by many, and many prefer this or JavaScript while others might like old school languages like Java or C++. I See Python as another “new kid on the block.”
Python is easy to learn and great for #CodeNewbies wanting a gateway into coding.
Python is excellent for data science and is the most popular language when it comes to things around Machine Learning or data visualization.

And that’s the list. I didn’t even know what types of frameworks there were for Python, where it came from, reasons why there were fangirls/boys who lived by Python, or how it came to be. So let’s dive in.

How Python Became Python

So by now, I think it’s safe to say that I will be starting out each one of these blogs with a little history lesson. I think it’s pretty interesting to see how all of these technologies came to be. Python emerged on the scene in 1991 and was designed by Guido van Rossum. He also founded the Python Software Foundation at that time. It was born to help with making code a little more readable, which I find great, because it opened the doors of coding to so many more people and I am sure it helped build out a path where people don’t have to have a four year computer science degree to become a developer. If you want a more full history of where Python came from and what led Guido to design it, you can check out this article here.

By 1999 Guido decided to give a list of his goals for the programming language:

an easy and intuitive language just as powerful as those of the major competitors;
open source, so anyone can contribute to its development;
code that is as understandable as plain English;
suitable for everyday tasks, allowing for short development times.

From there, Python has exploded and does exactly what Guido hoped, it became an easy language for folks to learn to code. Since it is open source, frameworks and ecosystems have been built to make Python a go to coding language for many across the world.

What Makes Python Different (from Java, JavaScript, C++) and Where it Excels

Beyond Python being understandable, easy, intuitive, and useful for everyday tasks like rapid app development, what makes Python different and where does it beat out its “competitor” programming languages? Well as Guido stated in his goals, the code is in plain English so it doesn’t feel like you are looking at a foreign language like some other programming languages. This means people can learn it faster and develop applications and tools quicker using Python. Today, major companies use Python for building out their products including Dropbox, Uber, Buzzfeed, and Pinterest… to name a few.

Python is ideal for data science, including machine learning, data visualization and analysis. It's the preferred language for all things data science because of how easy it is to learn and use, its scalability (which in this case means it can be faster than other languages and more flexible for solving different problems), and there is a huge selection of data science frameworks available within the Python programming language. If you need to review the concept of frameworks within a programming language, you can reference my first article in this series on JavaScript here.

Scripting is another use case where Python is ideal. I didn’t know what scripting was before this blog, but after doing some research I learned that it is writing code to automate small tasks such as counting contacts that match certain criteria or making simple API calls. APIs, or application programming interfaces, are defined calls or requests for your code to perform an action. For example, an API call for HarperDB is "create_schema" and when you call that from the API, it will create a schema in HarperDB.

Django Unchained (Not the killer movie, but the killer framework)

Just as JavaScript has many frameworks beneath it, Python has an entire ecosystem as well. The most popular framework from what I have seen on the web is Django. I could be wrong, comment below what your favorite Python framework is! Django’s tagline is, “a web framework for perfectionists with a deadline” and well if I was a developer, it sounds like the perfect framework for me. It’s very high level and great for rapid app development which fits in nicely with Python as a programming language overall. Here are some other popular frameworks along with what how those frameworks are used:

Pyramid- full stack framework
web2ply- full stack framework focused on ease of development
TurboGears- a highly scalable framework for Python
NumPy- a top general purpose data science framework
Scrapy- popular framework for data science
TensorFlow- the best framework for machine learning
Keras- a popular neural network library for Python

Did I miss any? Let me know!

Code with Joel-Python App and Machine Learning

I would be remiss if I didn’t mention that the reason I picked Python this week is because my team at HarperDB is hosting a code along featuring our Python SDK. We have invited Joel Wasserman, a Google Engineer and Startup Founder, to walk attendees through building out a Python app with HarperDB and then training a machine learning model on the data. Joel will be using the SciKit-learn Python package to train an ML model that predicts whether it's safe to go skydiving based on weather reports. We held a similar event last month with Cassidy Williams building a React App, so if you want a taste of what to expect, you can watch her code along here.

To wrap up it all up in a nice pretty bow, I will leave you with the highlights of what I learned about Python:

Python was designed in 1991 by Guido van Rossum and he created Python to provide a coding language in plain English that was easy to learn and easy to use. It is open source so that folks can build upon Python, and meant for everyday tasks and rapid development.
Python is indeed loved by many for how simple it is and how easy it is to learn, it’s an excellent option for startups and companies looking to rapidly develop and modify a product along with code newbies trying to get their feet wet.
Python is excellent for data science use cases including machine learning and data visualization, while also being great for scripting and web app development.
There is a huge ecosystem around Python with endless frameworks including the popular Django and TensorFlow.

I would say, Guido van Rossum’s goals for Python have all been achieved and I can bet he is pretty proud of Python! If you want to practice your Python skills and learn how to train a machine learning model, RSVP to our free Python event!

SQL and Relational Databases Explained (By a Non-Developer)

Kaylan Stock — Wed, 07 Oct 2020 19:31:27 +0000

Welcome to the second installment of Developer lingo explained by a non-developer. How do you follow up with a term so widely used and intricate to modern development, like JavaScript? I decided to take it back to a more tried and true function within software development, SQL.

SQL stands for Structured Query Language and is used to communicate within and manipulate relational databases. It is good at handling structured data that includes relations between entities and variables of those entities.

Another Brief History Lesson

SQL has been around for quite some time with the first emergence of the language in the 1970’s when IBM researchers decided to take the findings from Edgar Frank Todd's paper, "A Relational Model of Data for Large Shared Data Banks," and create a query language originally called SEQUEL. Yup, just like JavaScript, SQL used to have a different name. Unlike JavaScript’s name change, SQL was changed due to trademark infringement, there were no sneaky marketing ploys hanging around. This name change happens around 1973, but I couldn’t find much on an exact date. Although the named changed, there is still an ongoing debate even today on the pronunciation of SQL, some saying “S-Q-L” while others say “sequel”. How do you pronounce SQL?

SQL slowly became the universal standard for relational database management systems(RDBMS) and remains an important player in the database world, but it wasn’t actually available to the public until 1979. A company called Relational Software released its commercial version of SQL called Oracle V2. If you haven’t already guessed, Relational Software would later become Oracle. After SQL became commercialized, products like MySQL were born out the desire of companies to not spend time managing their own database or writing their own SQL from scratch. It remains one of the most popular SQL database management systems today and set a standard for all database management systems that exist today.

To SQL or To NoSQL, That is THE Question

Ah, the question. THE question that everyone and anyone has heard, debated, and discussed if they know even a sliver of information about databases. First off, I will share my favorite blog on comparing SQL and NoSQL, written by HarperDB CTO, Kyle. He does an excellent job explaining the difference and where HarperDB fits in (we are kind of an oddball 🙂 in a good way). We also have an excellent article written by my colleague, Margo, on the different types of database architectures.

So when I was learning about SQL and NoSQL my first question was, if SQL is great, why do we need NoSQL? Well, like almost anything in the world, SQL has limitations. Relational databases typically scale better vertically than they do horizontally. What do I mean when I say scaling horizontally and vertically? Well that could in itself be an entire blog, so I will share this great resource summarizing scalability and what it means to scale in both directions. Keep in mind that scalability “is the capability of a system, network, or process to handle a growing amount of work, or its potential to be enlarged to accommodate that growth.”

SQL is powerful and can handle a variety of data. It can handle the data loads that we used to see back in the 1970’s, 80’s, and 90’s. As the world became more advanced and new technology emerged, we started to see more and more AND more data. Data sets grew, and they are still growing today especially with the rise of IoT and edge computing. Relational databases couldn’t keep up and it doesn’t help that SQL is, ehehmmm, structured and requires a schema for your data. This is where NoSQL comes in.

Large, usually unstructured data can be anything from tweets, emails, images, and documents, to video and audio files. As for SQL and RDBMS, relational literally means data is related rather than random, and these types of databases are typically tabular so at their core, they are not designed for unstructured data. (However, some relational databases today have built in functionality to handle this problem). Not to mention, the scale! As Kyle stated in his blog, relational databases can scale vertically, but this has limits and usually means migrating to a larger server. This process can be expensive, tedious, and frankly terrifying because so many things can go wrong and in 2020, data is gold, so losing it is kind of a big deal. NoSQL means, ehehmmm, no structure or schemaless, meaning you can just throw your data in, no structure necessary. You may also hear the term dynamic schema, which means the data structure changes dynamically as new data is ingested.

Think about the structure of NoSQL being a bucket you just dump data into and that data can still be sorted and interacted with, while SQL is a book shelf that you carefully plan out how you want to categorize your data.

The other main differences include SQL being table based while NoSQL is key value or document based, both of these relating back to the structured versus unstructured concepts. Think about the structure of NoSQL being a bucket you just dump data into and that data can still be sorted and interacted with, while SQL is a book shelf that you carefully plan out how you want to categorize your data. It’s faster and easier to dump data into the bucket and this bucket can hold a lot more data without the walls of the bookcase, but it’s harder to quickly find what you need. The book case is great because it keeps everything in a neat and tidy system, but what if piece of data could go on two different shelves or NEEDs to be on both shelves?

What is your favorite thing about SQL databases? What about NoSQL? Comment and let me know! Here is another great source, where they break SQL and NoSQL down like two different towns.

SQL is Here to Stay: NewSQL

Many databases claim to be NewSQL as it seems to be a hot new buzzword to some folks. It is a valid database category in my opinion, but there is confusion around how to group databases under NewSQL. As one of our co-founders at HarperDB wrote in his recent blog about NewSQL:

When we look at what defines a “NewSQL” database we see a few key things:

“…a class of relational database management systems that seek to provide the scalability of NoSQL systems… “
“….while maintaining the ACID guarantees…”
“Many enterprise systems … are too large for conventional relational databases, but … are not practical for NoSQL systems.”
“The only options previously available for these organizations were to either purchase more powerful computers”
“…or to develop custom middleware…”
“Both approaches feature high infrastructure costs and/or development costs. NewSQL systems attempt to reconcile the conflicts.”

When we first started HarperDB, we discussed having the capabilities to perform SQL and NoSQL and we thought people would instantly get how AWESOME that was…but they didn’t. They would respond with, So? This is because NewSQL was still a newer and not well defined term, people believed that databases like MongoDB had both because they provided something SQL-ish. It wasn’t really SQL, but to most folks it meant they could do both. (Tools like MongoDB actually incorporate complex integrations to try to achieve SQL functionality, but HarperDB provides that out-of-the-box in one simple tool). So NewSQL is the true blending of both NoSQL and SQL. Data has become so complex, with massive amounts of it coming in from millions of sources. NewSQL is the answer to our increasingly data focused world.

NewSQL is only going to keep growing and evolving and it’s an excellent choice for many use cases. For one, it’s great for startups and newer companies that haven’t dug their heels into a legacy system with complex architectures that have cost them a lot of money. Individual developers working on side projects might choose NewSQL as well. Another example is use cases where traditional ACID compliant SQLf is needed (as opposed to BASE compliance more commonly related to NoSQL databases), that also have a growing need for high performance and larger scaling capabilities at lower costs than traditional RDBMS systems stacked on top of servers. NoSQL database users might also see a need to implement ACID compliant SQL while maintaining the performance and scale that they have come to love with NoSQL.Even coding schools are looking at using NewSQL products so that they can easily expose students to SQL and NoSQL with one tool.

Wrap it Up

In conclusion, as our world evolves and we become more and more technologically advanced, our data evolves right along with us. SQL is never going away, it was the first type of universally acknowledged language for databases after all. NoSQL and SQL databases are vast, mainly including their structure, scalability, and performance. Each have important roles to play in 2020 and will continue to be critical to running a business or project moving forward. NewSQL is a modern solution to a problem that didn’t really exist in the 1980’s, but now, one could argue that needing the “best of both worlds” is THE biggest problem for many enterprises and startups alike. What do you think about NewSQL? I am sure I missed some other differences between SQL and NoSQL, drop some knowledge in the comments!

Your Hackathon Project NEEDs a Good Pretzel Necklace

Kaylan Stock — Wed, 30 Sep 2020 16:17:06 +0000

October is upon us… and along with pumpkin spice lattes (or pumpkin beer) I’m seeing a lot of buzz around upcoming hack events in the dev world! Such as Hacktoberfest, API World Hackathon, and the launch of the 2021 Major League Hacking season. Just like Octoberfest wouldn’t be complete without your favorite pretzel necklace, a great hack project needs something special. A user-friendly, lightweight database enabling rapid app development could be the pretzel necklace to any project. Hackathons have been around for a while now. While we can’t say for sure the exact origin date, most folks attribute the first hack party to a team of 10 developers meeting in Canada in June of 1999 to avoid legal problems with exports of cryptographic software in the US.

Hackathons have exploded worldwide ever since that fateful day in 1999 into something that can help companies or small teams develop products and use cases quicker while recruiting tech talent and scoping out locations for new innovation. These events also give developers the chance to practice and polish their skills, helping them to become better candidates for software engineer positions.

Fast forward to 2020 and communities like Dev.to and Digital Ocean are hosting awesome events like Hacktoberfest, encouraging further inclusion and education in the developer space. Why not make a database, and specifically when I say database, I mean HarperDB 😉 the pretzel necklace to your upcoming hack project?

Lay a Strong Foundation Quickly and Easily

Raise your hand if you have a hard time STARTING a new project, but then once you’re in it and find your groove you can’t STOP working? HarperDB enables developers to spin up a database within minutes, just watch our friend Cassidy Williams build the beginning of a React application on top of HarperDB in under an hour! Similar to pretzels being an easy way to avoid long lines at food booths at beer festivals, HarperDB is the easy way to get your project started and avoid project paralysis. The pretzels also keep you from getting too tipsy at your favorite beer festival, and you could say HarperDB will keep your project from getting too drunk with complications (REACHING….I know).

Why HarperDB Might be a Good Fit for Your Hack Project

User friendly, built for developers of any skill level
Flexible & lightweight, SQL & NoSQL, runs anywhere
REST API
Sleek Management Studio, limited database configuration required
Language agnostic
Marketplace with open source extensions enabling quick & easy development

HarperDB provides you with a few different features to make app development quick and painless. Our API is a single endpoint and ALL database operations are available via the API. Because of this, HarperDB is language agnostic so don’t fret about learning any proprietary languages when you only have one month to build your hack project. Our Management Studio is intuitive and user friendly so you can easily monitor and make changes to your instance(s), fully equipped with all the resources you need like code examples and video tutorials! We have a marketplace where you can find connectors and SDKs to help you get up and running even faster, while expanding upon the features and functionality of HarperDB. Think of the marketplace as the variety of snacks you can add to your pretzel necklace to make it even more delicious and efficient while keeping your hunger at bay. (You’ll see below a picture of a guy who added a LUNCHABLE, that's right an entire Lunchable, to his necklace).

Find Inspiration from Other Pretzel Necklaces

…Or in this case other developer examples. HarperDB has hosted two hackathons in the past and we’ve had excellent and talented hackers build cool stuff on top of HarperDB. Killer inspiration could be the thing that takes your next hack project to the next level. You could keep it easy and build off this simple telemetry monitor or try out building the next addictive game app like Connect 4 Linguals. Or, check out this Sample Programs repo on GitHub for a fun side project.

The winner of our first hackathon created a secure healthcare portal that would eliminate data silos that currently exist across different providers and doctors for one patient. Key stakeholders including your various doctors, family members, nurses, mental health therapists, and even fitness instructors or nutritionists, don’t have a way to communicate. If you’re looking for inspiration, use this common problem of data silos to launch your project and find a solution for integrating data for something that is important to you. Everyone loves examples and HarperDB has quite a few. (By the way check out some pictures of my favorite pretzel necklaces that I saw on the internet, the one with cheese is my favorite because…cheese!)

Happy Hacking!

So what are you waiting for? With HarperDB you now have an easy path to getting started with rapid app development, and we’ve provided examples to help give you the inspo you need! Our dev team is always here to help out, we love to watch folks build new stuff on HarperDB. You can join our Slack channel to chat with the community or email support@harperdb.io if you get caught up. Whatever you do, just keep coding, just keep coding, just keep coding. Oh and if you make a pretzel necklace to enjoy while you’re hacking share it in the comments section!

JavaScript Explained (By a Non-Developer)

Kaylan Stock — Thu, 30 Jul 2020 17:48:38 +0000

An honest interpretation of all things developer from the person you would least expect, a marketer.

Ever wonder how people on the outside of a specific industry such as software development understand and describe the common terms within that field? Even if you haven’t, I am here to start a series of posts explaining developer and technical terms that might seem like a foreign language to folks who aren’t part of the developer world.

The first term I decided to dissect was JavaScript. Love it or hate it, JavaScript has become THE coding language to know and understand. There are plenty of programming languages out there: Python, Java, C, C++, JavaScript, and many more. I choose JavaScript because it's the language I hear the most about. Before I did my research, I would have told you that JavaScript is the catch all for coding languages, it’s easy, takes on many different forms, and rules the web today as we know it. I also picture two devs sitting together over some delicious craft IPAs arguing over whether JavaScript is the best or the worst. It’s kind of like beets, you either love them or hate them (I love them in case you were curious, don’t judge!) After doing my research, if I had to sum up JavaScript in one sentence, I would say:

JavaScript is the lightweight, easy to learn, multi-paradigm coding language that was born to make webpages interactive and dynamic, and has morphed into a language with multiple frameworks, many use cases, and whose variables include numbers, strings, arrays, objects, or functions.

Was that a mouthful? Yes, and I bet you can sum it up better than me. If you want to take a stab at it, drop your one sentence explaining JavaScript in the comments!

A Very Little History Lesson

The history behind JavaScript was pretty interesting to me and I think you could say my age was showing when I completely forgot about a time when webpages were static (I was born in 1993, which is when the first web browser became available so cut me some slack!). JavaScript first appeared in 1995 after a major player in the web browser space, Netscape, decided they needed something more than boring, static web pages. To do so they wanted to implement Scheme (another coding language that is a scripting language). I didn’t dive too deep here, as this blog is about JavaScript not building the web as we know it today so if you want to learn more about scripting languages or Scheme, you can do so via the links.

Netscape first enlisted Sun Microsystems (Oracle eventually acquired them!) and one of the OG coding languages Java to help with their endeavor. However, once those two options weren’t working, they asked Brendan Erich to create a new language with syntax like Java, but less like Scheme. Alas, LiveScript was born! Wait…LiveScript? Yeah, that is what they first called JavaScript for like a minute (3 months to be exact) and I am sure to this day there are people out there confused thinking JavaScript is a spin off of Java (I before today being one of those people). JavaScript is in fact not a spin off of Java despite the confusing name. Many believe because Java was the hot new programming language of 1995 Netscape decided to name it JavaScript as a… you guessed it, marketing ploy!

Meet JavaScript, Which is Not Like its Uncle Java

So I could go on about the history of JavaScript, but I want to also explain what it is and how it can be used. A lot of coding languages can be used for front-end and back-end development, but most are better suited for one or the other. I would say JavaScript is one of the few that can go either way. Of course we know JavaScript was born to make web pages dynamic, so you can use it on the front end, but now a days with so many awesome frameworks JavaScript can be used on the backend too, like say…HarperDB! We actually wrote our entire database in Node.js (I promise that was my only HarperDB plug).

What am I talking about when I say framework? Well if you’re a seasoned developer or even a really new developer you probably already know, but for those who don’t, a framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code. I will state that in layman's terms. Frameworks are like the cooking utensils of your coding language. They are all used to cook food, but they offer different benefits. A KitchenAid mixer might get you to a batch of cookies faster, but a charcoal grill will be better suited for steaks. Either way, you still have to cook for yourself. I really like food so food analogies are a big thing for me.

A quick Google search of top JavaScript frameworks would show you the above linked hacker.io blog and if you disagree drop in the comments your top ten (it's kinda like MySpace top 8 🙂 ). Here is their list:

Angular
React
Vue.js
Ember.js
Meteor
Mithril
Node.js
Polymer
Aurelia
Backbone.js

Beyond those 10 there are many many more. I tried to find an exact number and I don’t think one exists. My understanding is everyone and their mother has created a JavaScript framework. That’s freaking cool! That means a huge ecosystem and community has been built around JavaScript and it also means you can probably do anything your heart desires with JavaScript.

JavaScript is considered a multi-paradigm language so again, you can do a lot with it. Programming paradigms are “ways” or “styles” of programming. A few highlighted paradigms are in this great resource here. The programming paradigms JavaScript is included in are functional programing, prototype-based object oriented programming, and event driven programming. Did I miss any? What is your favorite programming paradigm and why?

I don’t want to spend too long on why JavaScript is bad, I am sure someone will think that I’m being biased, but I feel like we should end on a high note. I found this article amusing and informative on why people hate JavaScript and I honestly am intrigued. I don’t often hear from the devs at HarperDB that JavaScript sucks, but then again since we use it heavily here I assume you wouldn’t want to work at HarperDB if you hated it (lol, is this true? Do devs pick jobs solely based on programming languages? Will you work at a job that uses a programming language you hate?)

Conclusion (Even though I could write a 10 page essay right now)

Hate it or love it, JavaScript is here to stay. From its humble beginnings there have been strong opinions about JavaScript and I am sure those opinions will carry on into the future. I think the fanboys and the haters of JavaScript both have valid points about the coding language that is not just dominating the web, but even non-web based applications. It’s EVERYWHERE. It’s amazing that there is such a large ecosystem of developers to support others and so many frameworks that can work on the backend and frontend. This will be the first of many posts, but I like to think it’s interesting looking at the developer industry terms from an outside perspective. Let me know what you think, what terms you would like to see next, or just say hi!

SDKs, App Games, & Zapier Oh My!

Kaylan Stock — Tue, 21 Jul 2020 17:14:19 +0000

The Cloud Hackathon that Brought it All

Last month, the HarperDB team hosted our second hackathon and the participating teams did not disappoint. We had 10 overall submissions, and each was more unique than the last. The challenge was to extend the capabilities of HarperDB, whether that be creating SDK’s/add-ons to benefit developers, or features making HarperDB more accessible to non-developer folks. We selected the top three teams to award prizes to, which was incredibly difficult because all the teams brought their A-game. I wanted to take a moment to summarize some of the projects so that the world can get a glimpse of the hard work put forth by the developers behind the hack.

First Place: A HarperDB Zapier Integration

First place was awarded to Chandan Kumar for his Zapier integration to HarperDB. Zapier is the catch all for connecting every and any app on the planet, so it was a no brainer for the dev team to award this project the top spot. The Zapier integration not only extends the capabilities of HarperDB Cloud to integrate with hundreds of web applications, it also helps automate workflows from those connected apps to HarperDB. If you can’t tell, we love simplified and easy to use around here.

Features included authentication, triggers to get all schemas, tables, and attributes, and future scope features such as triggers for create and update record. Chandan implemented a number of search actions including find a record, find records with custom query, and find or create a record. He also implemented a number of create actions. Chandan’s Zapier integration will be available to the public as part of the HarperDB Marketplace launch. Check out his code now by visiting his Github project.

A Close Second: SDKs for Python and Kotlin

Dhruv Kanojia, a participant and winner from our first hackathon took second with two SDKs for HarperDB Cloud. The first SDK he created was for Python, something that had been requested from HarperDB many times. With a Python SDK, HarperDB users now have access to one of the most widely used languages by developers and data scientists alike. Overall, the SDK simplifies HarperDB data access, ingestion, and modification.

The second SDK was created for Kotlin, which has slowly been replacing Java in app development over the years, and is an easy to use option for beginners learning to code. This SDK will save developers time while also making it easier to put a database on the backend of their app.

Third Place: Self Described “Newbie” Developers Creating a Fun Language Game

Jenell Weitz reached out asking if we had a separate contest for newer developers, but her and her teammate Peter Kurjanowicz ended up taking third. They were very creative and the execution was on point. I was impressed with the work they put out and I don’t think Jenell gave herself enough credit upfront. 🙂 For their project, they created an app game using HarperDB called Connect 4 Linguals. This game is similar to the original Connect4 we all grew up playing, except it’s digital and uses words to fill the rows and columns. It can be played in any language making it a dynamic game to play with folks across the world.

Their team used Vue.js, Python, Flask, Socket.io and a few others on top of HarperDB Cloud to build Connect 4 Linguals. Features included a random topic generator, the ability to create your own topic (which would be saved to HarperDB for future use), and a challenge button allowing players to debate their opponent’s entry.

Check out the project on Github.

Open Research Platform and HarperDB

While Ethan Arrowood didn’t end up placing, we loved the concept and project he put forth, another two time hackathon participant. The fundamental feature, as Ethan states, is the anonymization of posts. Researchers can decide when to reveal their name when posting research and stay anonymous until then. The posts come directly from the server, you can strip away name before sending it back to the client. Ethan used Typescript and Node.js to write his app; React, Parcel, and Bootstrap for the client; and Fastify for the server. Entities include users, researchers, and posts. While Ethan’s project was a simple concept, it was a great use case and well executed.

And Finally, Notes to HarperDB

Another great project that didn’t place is this Lotus Notes* to HarperDB migration tool by Jason Freis. Some folks reading this article may have heard of Lotus Notes, others may have not. Notes is typically considered a “legacy” system, but still has a decent sized footprint in the enterprise world. The feedback the HarperDB team has received about using Notes today is…well…not great. It’s outdated, bulky, and shows its age, but is kept around for custom processes and archival purposes. The driving factor of this is primarily the challenges and up front costs that come with migrating data out of the legacy application. In his project, Jason highlighted the benefits of migrating from tools like Lotus Notes to HarperDB:

-Easy to move data into a new platform (HarperDB supports native formats & doesn't change any data!)
-Clever querying using standard SQL (even when the data is not normalized in any way)
-Existing non-Notes dev teams can be instantly productive with legacy data via REST API or Drivers
-No dependence on a Notes/Domino server, no longer need specialized development skills

*Lotus Notes was sold by IBM to HCL in 1995. Many folks still refer to it is Lotus, but others may know it as HCL Notes.

But wait, there’s more

If you missed the hackathon, but would be interested in getting PAID to work on HarperDB, we recently launched our bounty program where you can find projects on our feedback board, “claim” them and then get paid to build that project. Thank you again to all the amazing submissions we received, until the next hackathon...

LMDB Deep Dive: Interview with a CTO on using the Open Source Key Value Store

Kaylan Stock — Wed, 15 Jul 2020 17:04:41 +0000

Recently, the HarperDB team invited the folks behind AlaSQL, a popular client-side in-memory SQL database, to a virtual Q&A. It was interesting to learn more about AlaSQL and how HarperDB uses AlaSQL on the backend. This got me thinking about one of the other tools we use within our tech foundation, LMDB. While we have not yet had a similar event with the creators of LMDB (hopefully in the future!), I was able to catch up with our CTO, Kyle Bernhardy, to learn more about how HarperDB incorporates LMDB and what it's like to work with the open source key value store. Kyle was the lead in implementing LMDB into HarperDB so it was highly insightful to hear about his experience. You can listen to the full 30 minute interview here.

Kaylan Stock: Well, thank you, Kyle, for doing this interview with me today. I'm excited to learn more about how we implemented LMDB and all that good stuff.

Kyle Bernhardy: I am just here to share what I know.

Kaylan: Well, let's dive in. So my first question. Pretty basic one. What is LMDB? For people that might not know.

Kyle: So LMDB, it's a really fast, really lightweight key value store. And the one differential with LMDB is it’s an embedded datastore. So that means that it embeds in your code. It doesn't run as a separate server. It actually acts as a library. And you just call functions on that library to execute the functions that you need. So that keeps it really lightweight because there's not some extra resource running on the side. So it actually just runs in line with our code.

Kaylan: Awesome, and we love lightweight and compact here at HarperDB so it's a good fit.

Kyle: Simple as possible.

Kaylan: Yes. All of that. So how does HarperDB use LMDB on the backend?

Kyle: Sure. So LMDB is our new data storage mechanism. When we started the company over three years ago, our initial data storage mechanism was something that we had created a patent around and it was based on the file system. And so when you inserted let’s say, a record or an object, we would break it all apart by attributes and then store each element separately as a file.

And that had some real good benefits, but it also had some real big tradeoffs. One of the big tradeoffs was searches. Also, there are some issues on the file system as well with things called inodes (index nodes). And on the scale of data, it sort of fell over on itself with our old data mechanism. So for LMDB that's our replacement data storage mechanism, and it allows us to still do data modeling, very similar without breaking records / objects apart, auto indexing and all that.

Kaylan: So that's awesome. And doesn't LMDB help with performance too or is that more the AlaSQL side of it?

Kyle: Well, we did do some performance improvements in the SQL side. Sam Johnson, one of our engineers, had done a lot of work on our SQL Engine to improve that. But the lower level below that is the data itself. And we got significant performance improvements from C.P.U. utilization, memory utilization, disk utilization and really across the board. We got significant improvements just from the hardware utilization of your computer, server, or whatever it is that you're running.

Kaylan: Yeah. I think everyone here at HarperDB is a fan of LMDB for sure. It's a really cool [product]... it's open source, isn't it?

Kyle: It is. And we're using a node library because LMDB is written in C and HarperDB is written in Node. The really nice thing with Node is you can import C as native node modules. And another open source contributor had created a great library for LMDB for Node. That's a big game changer and the implementation of it was very simple on the node library side. But we're essentially using two open source libraries that’s sort of like the bigger fish is eating the smaller.

Kaylan: That's a good analogy. So obviously, from what we've already talked about, it's been easy. But can you tell me more about the implementation process, what that was like? Was there anything that you disliked about implementing LMDB?

Kyle: Yeah, if you don't mind, I think it also goes in line with why we selected LMDB, because it really is the implementation. These are all very tied together. So I'll probably jump to that. So like I said, this is something that I've been thinking about for almost two years. And it really came down to we had a couple of POCs that we were working on and the feedback that we got from the POC's was [they] really enjoyed the product, but the read performance was not what they needed.

Around the same time we were also getting some feedback from investors and other people in the tech community, saying databases like MongoDB use multiple data stores. MySQL has different ways of using data stores. It's pretty common that the underlying place that you store the data is ultimately decoupled from the database itself. And so it's kind of smart to swap things in and out and give options because depending on use cases, someone may want to use a different data storage mechanism.

I spent the end of 2019 evaluating different key value stores with all the things that we'd learned and also making sure that whatever new technology we implement doesn't break our core mission, which is simplicity, a dynamic data model, a single data storage with SQL/NoSQL… All the things that we always talked about were very important for making it very easy for developers to, you know, put data in, get data out and do complex querying and simple querying, analytics. So I evaluated a lot of different products very quickly and while a lot of them washed out for various reasons, LMDB held up through the evaluation process.

There was a great node module built for it. I could build a dynamic schema around it. It was just very lightweight and it didn't put a lot of constraints on us in order to implement. So once I sort of did a quick “Bake Off”, I started digging in through the month of December. Can we mimic HarperDB’s existing data model, so not implementing it into HarperDB, but creating a very similar data model as if it was HarperDB and then running workloads through that sample.

Then I did a series of tests running these high scale workloads like doing inserts and different SQL queries and searches and all these things, comparing it to our file system data model to LMDB. And then [for] some workloads LMDB was, I think, six hundred times faster, that was on bulk CVS loads. Even for queries it was oh man, I think it was around like 60 times faster or something like that. And just like on all workloads, it was better than what we currently have. And so I did a write up and I disseminated that to the team. Because it's also a big level of effort, at the same exact time we also determined that we also need to roll out a cloud product.

And so Stephen and I sat down and discussed what resources were needed and ultimately decided I would work on this solo so the rest of the team could focus on HarperDB Cloud. So then the implementation process was, you know, the approach I took was to do a modular approach. And two of our engineers, Sam Johnson and David Cockerill, when they were working on a failed co-development project earlier in 2019 with another company’s key value store, they created a mechanism for us to decouple the data storage from our core logic. So there was already a pattern in place. They saved me probably months of work. So creating this modular design of creating the core functions, that just does the create, read, update and delete operations.

And also managing the tables, which LMDB calls environments. So when you create a table, we need to create this environment and then create an attribute when you need to create a separate key value store inside there. How do we track all that? So there is a lot of wiring that was specific to us so that it would then bubble up and make sense for HarperDB. And so creating these foundational modules and functions is where I started. And then building unit tests on top of that. So for everything I built, making sure that there was testing all the edge cases, because then I would test something and realize, oh, that doesn't work.

The most complicated thing I had to spend time on was search, which is no surprise. But, you know, it's just like adding layers on top of layers, and just doing this modular design. It took three months and then the testing took about another month and then it basically lined up. It was hard and by that time the managed service was right to deploy. So the timing all worked out really well and Kaylan you project managed me on that

Kaylan: Of course! I'm just thinking back to that implementation process when at one point you said you had 100 hundred errors when you did a test and then you fixed, like, one thing and then it just like fixed [everything]...that just was crazy to me.

Kyle: Yeah I can't remember what I fixed there..It's all a blur now. As far as implementing LMDB itself it's very easy. It was overall just more like I'd had all my requirements laid out and it just was cranking through them, I was like, I know what I need to accomplish. I know what I need to do. It's just the doing of it and getting through that process.

Kaylan: Yeah, definitely. I think it speaks a lot to how easy it was to implement and use that you did it alone and well, while you were in it, it felt like a long time, but three months to me just doesn't seem like that long of a time to completely implement this new tool. So, yeah, I mean, it's awesome.

Kyle: And to give us that level of performance improvements. Yeah. It was huge. And you're right, it is a very easy product to work with because, yeah, if it was complicated. I might still be working on it.

Kaylan: That just doesn't fit with our style here at HarperDB. And so I guess you may have already answered this in a sense. What's your favorite feature or aspect of LMDB?

Kyle: I have to pick just one?

Kaylan: OK. You could give me five. Yeah. Give me your top five or whatever.

Kyle: Yeah. I think overall, like from an architectural perspective of the product, what I really love about what they did in the implementation is they have something called a memory map. And so what that means is when you go to access or insert data, the memory...it actually assigns the byte address of an entry in that file into memory, and so it acts as if the data I'm trying to fetch is in-memory. So the very first call to get that item of data is as slow as just pulling it off of your SSD. But then the second call, the byte addresses are already cached and mapped in memory. And so it's acting as if it's an in-memory database.

So it has the speed of that, but it has the persistence of an on disk database. And so we're getting the benefits of both. And in any other key value store, I've not seen that implementation. It creates massive efficiencies. And it also aligns with when we started HarperDB, we wanted to leverage the file system. That's exactly what Howard Chu (the creator of LMDB) and [LMDB's] other engineers have done, is they're leveraging how file systems work, how virtual memory works on operating systems and using existing technologies. And it’s a really clever way to solve really complex problems. I think that's overall my favorite thing. It's just super smart about, and efficient about how they're accessing data.

I think the other thing, too, is they're using a B plus tree that just creates really efficient searches rather than like log structure merge tree or LSM, which are used in other implementations like LevelDB. Also, they're (LMDB) natively acidic and so meaning in the database world, it's Atomic, Consistent, has Isolation and Durability and that's native to the datastore. So we're able to lock a transaction. Anything that we're doing during that transaction does not impede the readers. So there's no isolation concerns, and then that data doesn't show up until we actually commit the data. And if something fails inside that transaction, it just rolls back. The readers never see it. So there’s this complete division between the readers and the writers and the writers and the readers. They don't impact each other.

Kaylan: Yes, definitely. I think you've kind of already touched on what your least favorite thing was about working with the tool. Was there anything you wanted to add?

Kyle: As far as specifics of LMDB itself, you know, nothing really comes to mind. I know there were things I struggled with just off the top of my head right now. I have no major complaints, a slight hurdle I had to figure out was handling various data types. I ended up leveraging the Binary data type as it allows for all kinds of data type.

Kaylan: Do you have any tips for people that are looking into using LMDB or incorporating it into their product or project?

Kyle: Yes. Yeah, I think you know just going through a good process of understanding what you're trying to achieve up front. I mean, it's sort of more basic design principles, but specific to LMDB. You know, there are some quirks with working with LMDB before you begin the transaction to make sure you initialize all of your key value stores. Because if you tried to do it inside the transaction, it'll blow up.

So there are some little tricks to how you need to initialize things. I'm just trying to think of some other kind of gotchas. Yeah, opening and closing environments, if you do them in the wrong order, you'll end up in a weird state with your data or your process will hang. Which I experienced one time when I was initially vetting the product, I almost gave up because all the sudden it just started hanging.

Actually to go back. Another [favorite] aspect I have of LMDB is one of the big communities that uses LMDB is the data science community and Python. There's a big community that uses it. And there's a lot of Stack Overflow articles and posts that I could access to understand how to use LMDB. So while I'm using it node, it's still the same tool. It's just the language is different. But the way you interact with it is all the same. So I was able to get online help without having to reach out to the actual development team.

Kaylan: Yeah, that's nice. How long has LMDB been around?

Kyle: Its initial release was 2011, so it's been around for nine years. So that's the other reason for choosing it was it's a well established project. It's been around for a long time. You know, nine years is a long time to work kinks out and bugs and understand different architectures.

Kaylan: Yeah, definitely. And maybe you don't have anything you would change, because I know you've been speaking so highly of it. But if you could change anything about HarperDB's implementation of LMDB, what would it be?

Kyle: I mean, right now, probably nothing. If you talk to me in like six months... but for now, I feel like it's really solid. You know, through our managed service, we're having users hit it and straight downloading the product. And we've not had any issues with data writes. Data reads, like a very low level. So the implementation now feels really solid. The thing is I think any issues would not be on LMDB itself. It would just be on what we did on top of it. I don't see any right now. It's more about what I want to do with it.

Kaylan: Yeah. And on that note, that's like perfect leading into my final question. What do you want to do in the future with LMDB and HarperDB? Where do you see that going?

Kyle: Near term, we are leveraging LMDB to store transactions. This will allow us to show the history & audit trail of your data by time, user & record id. We will also use this as a replacement for our existing clustering catchup data store, which is currently an append only file log. Longer term, I want to allow users to predefine data types for specific attributes, the key benefits will be enabling constraints on data which enhances data integrity as well as improves performance for searches.

Kaylan: Very cool. It sounds like you have a long list of things you want to get done with LMDB so that's awesome. And that actually was my last question. It's just cool to you know, I've watched you implement it, but it's kind of cool to just talk about the process and like, how you came to [choose] LMDB. It's very interesting.

Kyle: The more I researched, the more I read and the more use cases I found that made me feel more confident about the choice that we made. For this to be like our default underlying datastore. It's a great product. I hope someday we get to talk to Howard Chu who created it because he is super smart. I think [it would be] a cool conversation with him.

Kaylan: Yeah, I think I would love to send this to him. I'm sure he'd be stoked to hear all of your feedback. And it would definitely be cool to do a similar showcase that we did with the AlaSQL team. So yeah, that's definitely something we should look into and maybe get on the books depending on if he's open to it.

Kyle: Yeah, yeah. I hope so too. I think he lives in Colorado.

Kaylan: Really? That's cool.

Kyle: I think he might be on the Western Slope, but I'm not totally sure

Kaylan: That would be super cool if he was living right next door to us.

Kyle: He's just down the street.

Kaylan: All right, Kyle. Well, thank you so much for your time. And I am excited to write up some info on this awesome interview, and I'll definitely share the recording out and yeah, I appreciate it.

Kyle: Thank you. This is great. Thanks so much.

The full 30 minute interview is available to listen to here