Language:
switch to room list switch to menu My folders
Go to page: First ... 16 17 18 19 [20] 21 22
[#] Tue Jul 20 2021 19:11:07 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

2021-07-20 15:52 from Nurb432
In our cases its specific 'apps' these people provide, so locking
them down is the best way to go.

That's very different from the use-cases I've been working on for the last 10 years. I'm currently working at the second company (an app provider, I guess you could say) where everything we do is hosted in the cloud. All our operations. We could have hosted in a traditional colocation datacenter, but for newly-launched businesses, the cloud has replaced that.

So from the standpoint of our operational philosophy, the goal (not always achieved in practice, just a goal) is that every Amazon EC2 instance that we launch (or Docker container running on an ECS cluster) is sort of an anonymous worker bee, part of the hive. Machines may not stay around very long. In fact, it's better if they don't, so we can relaunch it fresh, with the latest kernel patches, and we don't get into a situation where we have a stateful machine that has an uptime of 643 days that nobody dares to touch.

Machines should be as stateless as possible and some companies prefer to relauinch a new EC2 instance on every deployment, just to enforce the best practice that machine launches are always automated and scripted, never involve manual intervention.

There's a lot more to unpack about this, but I'll stop there. We don't need, require, or offer VPN connectivity to our customers (yet), but if we did, I suppose we might find a way to present a static *internal* IP to them if we had to. We can do static external IPs through Amazon's "Elastic IP" feature.

What I'm suggesting here, is that for customers who demand it, a static IP might be an abstraction that a service-provider might present, but internally there might be a swarm of ephemeral worker bees with short-lived dynamic IPs behind the scenes.

[#] Tue Jul 20 2021 19:34:05 EDT from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

Ya, sounds like we are in different environments.  Our way would not work for you, and vise-versa 



[#] Fri Jul 23 2021 14:13:02 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

In a cloud environment, things like security and name services are often handled out of band.  If you're implementing their whole stack, the IP address doesn't matter a whole lot.

In a good cloud environment, launching a virtual machine that is intended to be persistent ought to offer an address lease that is long enough that it is essentially permanent, because in the real world, people use IP addresses.

"Cloud native" software doesn't care because it will usually do something like start itself up and then register with a load balancer.



[#] Fri Jul 23 2021 17:22:37 EDT from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

Which in our case, would have the static IP.  

I agree consumers wont care about what is behind it. .  But we care about the LB

Fri Jul 23 2021 02:13:02 PM EDT from IGnatius T Foobar

"Cloud native" software doesn't care because it will usually do something like start itself up and then register with a load balancer.

 



[#] Sun Jul 25 2021 11:56:22 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

In a good cloud environment, launching a virtual machine that is
intended to be persistent ought to offer an address lease that is
long enough that it is essentially permanent, because in the real
world, people use IP addresses.

This is the way it works in Amazon EC2:

* When you launch a machine, its internal IP is assigned dynamically but is essentially permanent and lasts for the life of the machine. That may not be nearly enough for people who want the ability to *relaunch* that machine on different hardware and keep the same IP.
* In that case, there are things you can do in VPC to hardcode an IP.
* You can also get static external/public IPs with the Elastic IP feature.

* But at scale, this kind of staticness may not work for every use case. We want to keep machines ephemeral and short-lived worker bees
* There are use-cases like the `awsvpc` network mode, which allows you to spin up a Docker container on ECS with its own dynamically allocated internal IP, which are not compatible with any kind of staticness.

[#] Sun Jul 25 2021 11:58:32 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


OBTW, amazon's native load-balancer product (1st-generation ELBs, 2nd-generation ALBs/NLBs) cannnot have static listen addresses. If you want that, I'm pretty sure you're rolling your own.

[#] Sun Jul 25 2021 12:01:56 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


Crikey, I need to be careful when I say Amazon doesn't have a certain feature. I end up eating crow because that's a moving target, and I'm already the old guy in the room.

Amazon *can* do static public IP - on an NLB. So this article sketches out a somewhat Rube Goldbergian method where you can use an NLB (with static IP) to the front of all your other stuff: https://aws.amazon.com/blogs/networking-and-content-delivery/using-static-ip-addresses-for-application-load-balancers/

There's more moving parts here, which sounds clunky, but you can do it.

[#] Sun Jul 25 2021 14:39:50 EDT from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

Until your 2nd comment, I was going to say i dont know how they are doing it, its all in the vendors hands so it could have been 'magic'.  We just said ' we need static ' and they made it happen. These are via non-public addresses routing only across the VPN, but i think the public side is too. While we added friendly A record DNS entries for what they gave us on public facing, id imagine they needed to be static. Or what they gave us was an A-record type of thing on Amazon side. Donno if that is how it is, or if that would even work, as never needed to look that far into it: "its the vendors problem".  But the internal traffic is 100% IP. 

They do have a problem that when they rebuild a server they cant pre-define the IP or set it themselves afterwards ( only the subnet ). Might get the same IP address back, but chances are slim. This hosed us a couple of times, as they forgot to tell us they did it and it changed, so everything we had internal broke. ( after the 2nd time we did open the entire subnet on the few ports we needed so down stream to us didnt need changing on the firewalls. but anything we were doing back up the VPN to them of course was hitting servers that no longer existed )

Tho all that said, this winter ( or coming spring ) we get moved to Azure, so all bets may be off?

 

 

Short story short of WHY we do this:

  • They provide a web based app, hosted on windows servers + MSSQL, now under their control being hosted in their AWS cloud. It used to be on site ( had a temporary CTO that basically said ' if your vendor supports it you are moving to cloud" even if it didnt make sense for your app ). Id love to move it back. Been nothing but problems since we moved.
  • Automation on their end reaches back down to things on our network for bits and pieces. Some of it read-only some R/W. So ports have to be open. Stuff like AD, or SCCM, solar winds, on-site SQL servers and various API calls to other apps we have. Some of our apps also reach back up to their SQL But all things that do NOT go across the internet.
  • Reporting runs on site, so i have to reach back to their SQL servers. Same here, no internet access to SQL. While its technically possible of course, security team would take us about back and shoot us. The data in there is way to sensitive to allow it.
  • The front end for users, IS availble on internet. As is their API. We jumped thru hoops for several years ( unrelated to the AWS move ), and finally got approval for internet facing, IF we had SSL ( duh ), SSO + MFA. ( and its subject to be pulled at any time ) So web clients, 90% no VPN for them.   Problem is 10% of my users cant do SSO/MFA as they are not part of our Azure tenant, so they have to access the web app across the site to site VPN and be on our network, or stop using the system.   Randomly changing IPS would effect them too.  Another agency that is trying to get their own install since we are not secure enough for them to share ours, i guess they are limiting who can use SSO by login, forcing their admin logins to be onsite. In my case its AD-forest based, and not a planned restriction, i just cant do it.
Being internet facing may go away soon, huge project where everyone has to re-justify it. Many are not able to. "convenience for our users" is not a valid reason anymore. 
 
 
The app, holds up our entire operation, and for what it does not do native, it still ties in to pretty much every process we have, and is a major part of several other agencies too. Its as integral as email so not trivial. Ya, a single point of failure, but sometimes its hard to avoid it. So we have contingency plans in place if perhaps AWS would go away for more than a few hours, or the vendor suddenly vanished ( we mandated a daily onsite backup, + we would just rebuild the app servers locally ). 
 
But hey, i have a 2nd guy that works with me now. It used to be me, and only me, for almost 2 decades. Its nice to be able to take a day off once in a while. While we did sort of divide up the work between us based on module, we do know everything so can fill in once in a while.
 
Long winded. sorry :)
 
Sun Jul 25 2021 11:58:32 AM EDT from LoanShark

OBTW, amazon's native load-balancer product (1st-generation ELBs, 2nd-generation ALBs/NLBs) cannnot have static listen addresses. If you want that, I'm pretty sure you're rolling your own.

 



[#] Tue Aug 03 2021 09:53:09 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

 

Tho all that said, this winter ( or coming spring ) we get moved to Azure, so all bets may be off? 

The smart money would be on distributing the load between AWS *and* Azure (and elsewhere if needed), and running command and control from neither.

Hybrid is really hot these days.



[#] Tue Aug 03 2021 17:31:07 EDT from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

They wont. Its a 100% shift.

Even lost their AWS people, not hiring more.

Tue Aug 03 2021 09:53:09 AM EDT from IGnatius T Foobar

 

Tho all that said, this winter ( or coming spring ) we get moved to Azure, so all bets may be off? 

The smart money would be on distributing the load between AWS *and* Azure (and elsewhere if needed), and running command and control from neither.

Hybrid is really hot these days.



 



[#] Tue Aug 03 2021 19:49:08 EDT from darknetuser

[Reply] [ReplyQuoted] [Headers] [Print]

2021-08-03 17:31 from Nurb432
They wont. Its a 100% shift.


I think something we should have learnt from this year and the last one is that you cannot put all your eggs in the basket of the same provider, specially if your applications are tailored to that provider and not easy to migrate to another one. I think IG is up to somethig with his mention of hybird solutions that keep the command-and-control out of hot spots.

[#] Tue Aug 03 2021 20:17:52 EDT from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

Oh, i dont disagree its the right thing to do.. But my vendor, they are not thinking 'ahead'.  After the move to Azure, they are going to get in bed with Microsoft even more i guess, and start using power apps with web-hooks instead of writing 'real' integration engines. 

Rumor too is they are going to replace their native windows services ( like for workflows , emails, etc ) with power apps.  And migrate their piss-poor reporting engine to PowerBI.  ( reporting took a huge hit with this upgrade. it was not great before, now it sucks. and sucks bad.  Old days they used crystal, which i like and use every day, but it got too expensive to embed so they got some stupid delphi report tool that was 1/2 assed. Now its gone and the new one is 9/10 assed.

 

( or was that logic apps? i donno, its all the same to me. Microsoft stuff. )

 

All i keep thinking  is the end of my career is near..  just a little longer.



[#] Wed Aug 04 2021 09:00:51 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

WTF is a "power app" ?



[#] Wed Aug 04 2021 15:55:37 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


Building hybrid cloud requires so much work on infrastructure-as-code... doable, but a significant pile of work even for an application as small as the one I work on for a living.

Then the infrastructure-as-code repo becomes the source of truth for deployment and ops, and it's just a layer of abstraction I havent' wanted the hassle of dealing with. I looove to be able to just keep the AWS admin console as the source of truth for config.

Someday this company may well grow and somebody will want to shove me under the bus and say "Yooooooou should have built somethign 10X more complicated..." but until then my job is far easier.

We are at a tiny scale. Our application runs on one single server running an Erlang VM. For reasons that were not my decision, we don't even have the ability to scale *that* out rather than up. So until we can even scale-out, load-balancing across a hybrid cloud would be beside the point.

[#] Wed Aug 04 2021 17:27:52 EDT from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

Its what Microsoft has branded as their ' low code' dev stuff. All cloud hosted.  Al tied to Azure. 

Wed Aug 04 2021 09:00:51 AM EDT from IGnatius T Foobar

WTF is a "power app" ?



 



[#] Sun Aug 08 2021 10:49:28 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

That sounds suspiciously like the same thing others call "serverless".

Enough with the silly terms.  We call that an API.



[#] Sun Aug 08 2021 11:04:59 EDT from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

i do think its more than that, since they also do GUIs and stuff.

Agreed a lot of it talks via an API, but the 'toolkit' lets you build what happens after the data is collected

 

not a fan, but its an end-to-end thing



[#] Thu Sep 16 2021 17:19:08 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]


Zoinks!

I think I may have figured out how to get the Static IP VPN service from Ace Innovative working only with software instead of using "their" router.[
This is something I tried to do last October when I first began using the service, but I wasn't able to get it to work. This time around I worked a bit more slowly and carefully, made some minor changes, and tested it a lot using the management tunnel before attempting the payload tunnel.

I switched it over for a few minutes and ... wow, all the inbound traffic for the citadel.org properties began arriving on the software tunnel! (Sorry if any of you were online just now and I interrupted your session.)

This means that I can now just keep a small virtual machine around that acts as a VPN router, bridge it to all of my server VMs, and that entire group of VMs can run anywhere, as long as they are together. I am *very* excited about this because it means I can move this stuff off my home server. (For those confused by this -- I have access to an excellent data center where I can run whatever I want as long as it doesn't call attention to itself, so this allows me to run as much capacity as I need but the Internet presence appears, from the outside, to be on the Ace Innovative network instead of at the server's actual location.)

[#] Thu Sep 16 2021 17:55:28 EDT from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

cool



[#] Thu Sep 16 2021 19:17:12 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

All right, it looks like I've got things moved over to the software router.
Cool!

Go to page: First ... 16 17 18 19 [20] 21 22