Author Archives: gmathis96

  • 0

Reimagining InetPortal

Over the past few months we’ve been building bigger applications, adding code to our current applications, and scaling in a way we never would have imagined a year ago. Our applications have more users, use more resources, and run on bigger servers within a bigger network. Currently, we have our code deployed within 3 data centers around the United States. Our applications currently become unstable from time to time as demand goes up and we get more traffic.

We’ve been thinking. Trying to solve the puzzle of scaling our platform. We’ve watched talks on how Google, Facebook, Yahoo, or any other large companies scale. We are proud to be announcing InetPortal 3.0. The new version of InetPortal will be rolling out over the course of the next few weeks and has many improvements to security and stability. We will be going over the improvements in this article, but we can’t give away all of our secret sauce.

InetPortal is containerized. Before, we looked at containers as the same as a physical node. Technically, that’s exactly what a container is, but let’s go a little bit deeper within this topic. InetPortal is a cloud platform, starting with version 2.x. Any virtual machine within a cloud environment is within a container, that way it has no access to any other containers within the same physical server. We wanted to take this a bit further. A server will now just be the number of resources we pay for from our provider. A container is the number of resources a single instance of an application is allowed to use, as well as a way to keep our apps separate from each other with no direct access to one another. This increases security a lot and gets us a lot closer to selling InetPortal as a service.

Autoscaling has been enhanced. InetPortal 2.x used to have a server that stayed logged into all other servers to check resource usage every minute or so. With the new monitoring tool, the servers report their health to one another, which not only allows us to see resource utilization for each server, but it also allows us to see the resource utilization of each container or each instance of our applications. If one server is unhealthy, InetPortal can move the containers away from that server, reboot, then move the containers back to the server automatically.

Different servers for different environments allows us to build a development platform within minutes and test our code without ever touching the servers running our production code. This allows us to find bugs before the user will without running the risk of crashing a live server. We can also deploy a completely separate production platform for other applications we build of coarse.

Scripts are no longer stored within network attached storage, or NAT. We used NAT because it was a quick fix for deploying code, but this was very slow. Of course, our code deployed as soon as we pressed save, going to the network every time we wanted to execute a PHP script was rather slow and expensive. We now use NAT explicitly for persistent storage across our network.

Bigger drives means more data, right? InetPortal 3.0 now supports dynamically scaling NAT. This allows us to create a Network Attached Storage device that is very small and make it bigger as we need more space. Our NAT will now start off small at 1GB and can scale up to 16TB of storage, on one drive.

Load balancing is also smarter. InetPortal now configures load balancers automatically, making use of the autoscaling features and the ability to move containers around a lot easier. Load balancers will be found all over the InetPortal platform as it makes things a lot more stable and improves our odds at a point of failure. Not only will you find one load balancer in these locations, you will actually find two. Load balancers run health checks on one another and have floating IP addresses assigned to them, when one load balancer fails, the other takes over and issues a reboot automatically.

Caching is now available. InetPortal 3.0 now supports database caching automatically on any MySQL query executed to the MySQL cluster. This allows caching to be enabled on applications that caching was never built into, making the entire platform even faster.

Over the next few weeks, we are expecting to see all of this make our applications 10 to 15 times faster. This will also allow us to scale quicker and easier! Can’t wait for everyone to try it!

  • 0

Introducing Open Source

Category : Open Source

The 4 Syndicate is a software company. We love to build software, work out bugs in existing software, and commit to open source. We love to give back to the community as we take away from the community. We use all kinds of technologies such as PHP, jQuery, Apache, Linux, Angular, Cordova, and tons more! We use these frameworks and programs for free. We think it’s about time to start giving back to the open source community because, if it wasn’t for open source, we wouldn’t exist.

Today, I am announcing we are going to start open sourcing some of the code that makes The 4 Syndicate operate on a day-to-day basis. The first project we will be open sourcing is phpSteriod, our internal PHP framework that runs all of our internal applications. There is some work we need to do to the framework to remove some of the dependencies that are available only within our network. We would love to see where the open source community will bring this framework.

We will also be open sourcing the framework that started it all, it only ran one application, which was BlabAway. We will be calling this framework BlabWork. This framework was in use for several years, running the BlabAway ecosystem, and will always be remembered by the team here at The 4 Syndicate.

Gary never likes to stick to something for too long, because after a while, it becomes out of date. We think phpSteroid is here to stay, for a while. If you have any ideas on the direction you think phpSteroid would go, commit to the open source project. We will be releasing a link to our GitHub page soon!